Java-Based Middleware
Download
Report
Transcript Java-Based Middleware
Java-Based Middleware
IT 490
Stan Senesy
IT Program
NJIT
Java-Based Middleware
• Categories
– Database oriented
• The most mature element of Java-based integration.
Includes the JDBC specification
– Interprocess
• Remote Method Invocation (RMI). Analogous to RPC
without many of the problems associated with RPC
– Message Oriented
• Java Message Service (JMS) is an application framework
that provides an API to allow message level connectivity
between JMS compatible systems.
Java-Based Middleware
• Categories
– Application Hosting
• Using an application server allows a Java app to serve as
an entry point to centralized resources.
– Connectivity
• Java Connector Architecture (JCA) provides a
standardized interface for integrating Java2 Enterprise
Edition (J2EE) applications amongst Enterprise Information
Systems (EIS)
Java-Based Middleware
• J2EE
– J2EE provides XML support through the Java API for
XML Processing (JAXP). This gives the capability to
verify, create, access and manipulate XML documents
directly from within Java
– JAXP specifications include:
• Java API for XML Messaging (JAXM) which allows
transmission and reception of SOAP messages
• Java API for XML Registries (JAXR) provides a uniform
standard for interacting with XML registries such as UDDI
or ebXML
• Java API for XML-based RPC (JAX-RPC) gives developers
access to a Java based RPC library based on the SOAP
specifications
Java-Based Middleware
• Transactional J2EE
– Java transactions are supported through the used of
the Java Transaction API (JTA).
– JTA enables high-level transaction processing in a
distributed environment
• Messaging J2EE
– Java Messaging Service (JMS) is a growing
middleware standard that has attracted a wide variety
of existing middleware vendors
Java-Based Middleware
• Distributed Application J2EE
– RMI provides a limited capability to interact with other
distributed object middlewares such as CORBA
– The RMI-IIOP extensions provide an addition to the
Java RMI that allows much greater interaction and
integration with CORBA ORBs.
– RMI-IIOP allows developers to connect the two
middleware standards together natively, with no
transactional binding needing to be implemented
Integration Servers
IT 490
Stan Senesy
IT Program
NJIT
Integration Servers
• “Integration servers broker information between on or
more target entities with greater ease than traditional
middleware models”
• Services that are provided by integration servers include:
–
–
–
–
–
–
–
–
–
Transformation
Intelligent Routing
Rules Processing
Message warehousing
Flow Control
Respository services
Directory services
Management
APIs and adapters
Integration Servers
• Most middleware solutions that we’ve explored so
far only deal with portions of the middleware
problem.
• Functions such as routing, data format and flow
control are not part of a typical middleware
package
• Integration servers help this problem by providing
a standardized set of services that may be
applied across a number of differing middleware
domains
Integration Servers
• Integration servers provide a number of differing
communications models, including:
–
–
–
–
One-to-one
One-to-many
Many-to-many
Any-to-any
Integration Servers
• In evaluating the applicability of an integration
server, we need to take the following steps:
– Evaluate the systems to be integrated. APIs that are
available should be indentified
– Use existing APIs to serve as entry points into existing
applications (preventing a rewrite)
– Whenever possible, use an adapter to insulate both
the target application and the integration server
Integration Servers
• Let’s look at some integration server services
more in depth:
– Transformation Layer
• We need to provide a standardized data representation for
all systems to be integrated. The functions here include
pattern matching, parsing, etc.
– Schema Conversion
• Database schema’s must also be compatible (data
federation). This layer is responsible for the conversion
to/from a common schema
Integration Servers
– Data Conversion
• In addition to changes to the schema, we might need to
make changes to the physical data structure as well.
– Intelligent Routing
• Messages need to be routed to the server that is best
available to process them. Often, only the integration
server itself can make that determination
– Rules Processing
• Data constraints might require knowledge from separate
systems to determine the applicability of rulesets
Integration Servers
– Message Warehousing
• It may become necessary to retrieve information for a
period of time. Warehousing provides a persistent storage
location for that data
– Repository Services
• Central location of information about source and target
applications (metadata, etc)
– User Interface
• Common location for the serving of a GUI that allows
access to the interfaced systems
Integration Servers
– Directory Services
• Allows integrated applications to intelligently locate any
data on the network. Examples include DNS, Netware,
Active Directory, etc.
– Management
• System management of the various applications that are
integrated. Current management tools include elements
that utilize SNMP.
– Adapters
• A common wrapper that allows easier integration than
rewriting an application from scratch.
Integration Servers
• Topologies
– Hub-spoke
– Multihub
– Federated