JavaBased Middleware IT 490

1
Java-Based MiddlewareIT 490

• Stan Senesy
• IT Program
• NJIT

2
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.

3
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)

4
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

5
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

6
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

7
Integration ServersIT 490

• Stan Senesy
• IT Program
• NJIT

8
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

9
Integration Servers

• Most middleware solutions that weve 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

10
Integration Servers

• Integration servers provide a number of differing
  communications models, including
• One-to-one
• One-to-many
• Many-to-many
• Any-to-any

11
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

12
Integration Servers

• Lets 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 schemas must also be compatible (data
  federation). This layer is responsible for the
  conversion to/from a common schema

13
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

14
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

15
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.

16
Integration Servers

• Topologies
• Hub-spoke
• Multihub
• Federated