| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
To address the EIS integration problem, the J2EE platform provides the following EIS integration technologies:
- J2EE Connector architecture--The J2EE Connector architecture provides a standard architecture for integrating J2EE applications with existing EISs and applications. The Connector architecture enables adapters for external EISs to be plugged into the J2EE application server. Enterprise applications can then be developed using these adapters to support and manage secure, transactional, and scalable integration with EISs. The 1.0 version of the Connector architecture focuses on synchronous integration with EISs. The 2.0 version (under development as part of J2EE 1.4) extends the core functionality to add support for asynchronous integration with EISs. We expand on the synchronous and asynchronous integration later in this chapter.
- Java Message Service (JMS)--JMS is a standard Java API defined for enterprise messaging systems. It is meant to be 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.
- JDBCTM API--The JDBC API defines a standard Java API for integration with relational database systems. A Java application uses the JDBC API for obtaining a database connection, retrieving database records, executing database queries and stored procedures, and performing other database functions.
The following sections cover the Connector architecture, JMS, and the JDBC API in more detail. For other sources of information on these topics, please refer to "References and Resources" on page 200.
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. See Figure 6.4.
Figure 6.4 Connector Architecture System and Application Contracts
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:
- Connection management contract--This contract enables an application server to pool connections to an underlying EIS, while at the same time it enables application components to connect to an EIS. Pooling connections is important to create a scalable application environment, particularly when large numbers of clients require access to the underlying EIS.
- Transaction management contract--This contract is between the application server's transaction manager and an EIS that supports transactions. It gives the transaction manager the ability to manage transactions across multiple EIS resource managers. (A resource manager provides access to a set of shared resources.) The contract also supports local transactions, which are transactions that an EIS resource manager handles internally.
- Security contract--The security contract enables secure access to an EIS and protects the EIS-managed resources.
Future versions of the Connector architecture will add support for a thread management contract, enabling an application server to manage threads for its resource adapters.
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.
Relational database management systems (RDBMS) are the most prevalent form of enterprise data store. Many application component providers use the JDBC 2.0 or 3.0 API for accessing relational databases to manage persistent data for their applications.
The JDBC API has two parts: a client API for direct use by developers to access relational databases and a standard, system-level contract between J2EE servers and JDBC drivers for supporting connection pooling and transactions. Developers do not use the contract between J2EE servers and JDBC drivers directly. Rather, J2EE server vendors use this contract to provide pooling and transaction services to J2EE components automatically. Note that, according to the JDBC 3.0 specification, the JDBC system-level contracts can be the same as the Connector architecture system contracts. Conceptually, JDBC drivers are pluggable resource adapters.
An application component provider uses the JDBC client-level API for such operations as obtaining a database connection, retrieving database records, executing queries and stored procedures, and performing other database functions.