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