J2EE Connector Architecture

The J2EE Connector architecture is the standard architecture for integrating J2EE products and applications with heterogeneous enterprise information systems. The Connector architecture enables an EIS vendor to provide a standard resource adapter for its enterprise information system. Because a resource adapter conforms to the Connector architecture specification, it can be plugged into any J2EE-compliant application server to provide the underlying infrastructure for integrating with that vendor's EIS. The EIS vendor is assured that its adapter will work with any J2EE-compliant application server. The J2EE application server, because of its support for the Connector architecture, is assured that it can connect to multiple EISs.

The J2EE application server and EIS resource adapter collaborate to keep all system-level mechanisms - transactions, security, connection management - transparent to the application components. This enables an application component developer to focus on a component’s business and presentation logic without getting involved in the system-level issues related to EIS integration.

Through its contracts, the J2EE Connector architecture establishes a set of programming design guidelines for EIS access. The J2EE Connector architecture defines two types of contracts: system and application level. The system-level contracts exist between a J2EE application server and a resource adapter. An application-level contract exists between an application component and a resource adapter.

The application-level contract defines the client API that an application component uses for EIS access. The Connector architecture does not require that an application component use a specific client API. The client API may be the Common Client Interface (CCI), which is an API for accessing multiple heterogeneous EISs, or it may be an API specific to the particular type of resource adapter and its underlying EIS. There are advantages to using CCI, principally that tool vendors can build their tools on top of this API. Although the CCI is targeted primarily towards application development tools and EAI vendors, it is not intended to discourage vendors from using JDBC APIs. An EAI vendor will typically combine JDBC with CCI by using the JDBC API to access relational databases and using CCI to access other EISs.

The system-level contracts define a "pluggability" standard between application servers and EISs. By developing components that adhere to these contracts, an application server and an EIS know that connecting is a straight-forward operation of plugging in the resource adapter. The EIS vendor or resource adapter provider implements its side of the system-level contracts in a resource adapter, which is a system library specific to the EIS. The resource adapter is the component that plugs into an application server. Examples of resource adapters include an adapter that connects to an ERP system and one that connects to a mainframe transaction processing system.

There is also an interface between a resource adapter and its particular EIS. This interface is specific to the EIS, and it may be a native interface or some other type of interface. The Connector architecture does not define this interface.

The Connector architecture defines the services that the J2EE-compliant application server must provide. These services - transaction management, security, and connection pooling - are delineated in the three Connector system-level contracts. The application server may implement these services in its own specific way. The three system contracts, which together form a Service Provider Interface (SPI), are as follows:

Java Message Service API

The Java Message Service (JMS) API is a standard Java API defined for enterprise messaging systems. It is a common messaging API that can be used across different types of messaging systems. A Java application uses the JMS API to connect to an enterprise messaging system. Once connected, the application uses the facilities of the underlying enterprise messaging system (through the API) to create messages and to communicate asynchronously with one or more peer applications.

A JMS provider implements the JMS API for an enterprise messaging system and provides access to the services provided by the underlying message system. Application server vendors include a JMS provider with the application server. Currently, vendors plug a JMS provider into an application server in their own vendor-specific manner. The Connector architecture 2.0 version defines a standard for plugging a JMS provider into an application server, allowing a JMS provider to be treated similarly to a resource adapter. However, a JMS provider will have a JMS API as a client API for its underlying enterprise messaging system.

A client application, called a JMS client, uses the JMS API to access the asynchronous messaging facilities provided by the enterprise messaging system. The EJB tier is the best place to implement JMS clients in J2EE applications. Since JMS supports peer-to-peer messaging, both source (or producer) and destination (or consumer) applications act as clients to the JMS provider.

A JMS domain identifies the type of asynchronous message-based communication supported by a JMS provider and an enterprise messaging system. There are two domain types: queue-based point-to-point domains and publish-subscribe domains. A Java application using JMS has a different application programming model depending on the JMS domain. For example, a Java application uses the JMS-defined queue-based interfaces QueueConnectionFactory and MessageQueue, among other queue-based interfaces, to interact with a point-to-point domain.

The EIS integration approaches may be classified as shown below: