6.2. J2EE Integration Technologies
Now that we have examined some common integration scenarios, let's look at the technologies that are available on the J2EE 1.4 platform to help with these issues. The J2EE platform provides a set of EIS integration technologies that address the EIS integration problem. These include relational database integration technologies (such as JDBC, Enterprise JavaBeans technology container-managed persistence, and Java Data Objects), messaging technologies (such as Java Message Service and message-driven beans), EIS access technologies (particularly the J2EE Connector architecture), Web services, and XML technologies for manipulating documents.
Let's briefly examine some of the available integration technologies. The section “Integration Design Approaches” on page 263 maps these technologies to different integration problems, illustrating when and how to use them most effectively.
6.2.1. Relational Database Integration Technologies
Relational database management systems (RDBMS) are the most prevalent form of enterprise data store. The J2EE platform provides three technologies for integrating data in RDBMS:
JDBC— Developers can use the JDBC APIs to access relational data in a tabular form.
Enterprise JavaBeans container-managed persistence (CMP)— Developers use container-managed persistence to do object-relational (O/R) mapping. By mapping database table data to Java objects, developers can deal with an object view of the data rather than a tabular, relational view. CMP also encapsulates the objects into higher-level managed components with transactional and security features.
Java Data Objects (JDO)— An O/R mapping technology that generates Java classes as opposed to components. Note that JDO is optional in the J2EE 1.4 platform. Since it is optional, your application server may not support JDO, or it may support JDO in a nonstandard manner.
“Data Mapping in EAI Applications” on page 274 explains when it is better to use JDBC, enterprise beans, or JDO.
6.2.1.1. JDBC
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.
Many application component providers use the JDBC 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 and may be packaged as J2EE Connector resource adapters.
6.2.1.2. EJB Container-Managed Persistence
Container-managed persistence (CMP), which is a resource manager–independent data access API for entity beans, has been expanded and enhanced in the J2EE 1.4 platform. CMP technology enables applications to be easily integrated with various databases or resource managers, plus it enhances portability.
CMP shields the developer from the details of the underlying data store. The developer does not need to know how to persist or retrieve data to or from a particular data store, since the EJB container handles these tasks. Instead, the developer need only indicate what data or state needs to be stored persistently.
In addition, a developer uses the same API—that is, the EJB CMP methods—regardless of the underlying type of resource manager. The same entity bean can thus be used with any type of resource manager or database schema. The technology makes it possible to develop enterprise beans that can be customized at deployment to work with existing data. That is, the same bean implementation can be deployed to work with many different customer data schemes. The mapping done at deployment may vary for each customer set up, but the bean itself is the same. Since the EJB container generates suitable data access code for each situation, the bean developer does not have to know or care about the underlying resource manager-specific code. Furthermore, since it has complete control over managing persistence, the container can optimize database access for better performance.
The J2EE 1.4 platform includes the most up-to-date EJB specification and CMP technology. Rather than declaring persistent variables in a bean's implementation, developers include abstract get and set accessor methods for persistent variables. Persistent variables are thus treated similarly to JavaBeans properties. Developers do not provide an implementation for these accessor methods since they are abstract methods; instead, the EJB container provides the method implementations.
The CMP architecture also includes container-managed relationships, which allows multiple entity beans to have relationships among themselves. Container-managed relationships are handled in much the same way as container-managed persistence. The bean implementation merely provides get and set accessor methods for these fields, and the container provides the method implementations. Similarly, the developer specifies the relationships in the deployment descriptor.
6.2.1.3. Java Data Objects
Java Data Objects (JDO) is an API that provides a standard, interface-based Java model abstraction of persistence. Application developers can use the JDO API to directly store Java domain model instances into a persistent store, such as a database. You may consider JDO as one alternative to using JDBC or enterprise beans with container-managed persistence. Keep in mind, however, that JDO is not standard in the J2EE 1.4 platform.
There are some benefits to using JDO. Since JDO keeps applications independent or insulated from the underlying database, application developers can focus on their domain object model and not have to be concerned with the persistence details, such as the field-by-field storage of objects. JDO also ensures that the application uses the optimal data access strategies for best performance.
It is not unusual to compare JDO to enterprise beans with container-managed persistence, since both provide object-relational mapping capabilities. The principal difference is that JDO maps database relationships to plain Java objects, while EJB CMP maps relationships to transactional components managed by a container. EJB CMP essentially provides a higher layer of service than JDO. Some J2EE application servers, such as the J2EE 1.4 platform SDK, internally use JDO to implement enterprise bean container-managed persistence.
6.2.2. Messaging Technologies
Messaging systems allow unrelated applications to communicate asynchronously and reliably. Not only do the communicating parties not have to be closely tied to each other, they can also remain relatively anonymous.
The J2EE platform provides the Java Message Service (JMS) API, which is a standard Java API defined for enterprise messaging systems. Along with JMS, the J2EE platform also provides message-driven beans. Message-driven beans are EJB components that consume and process asynchronous messages delivered via JMS or some other messaging system.
Let's take a look at messaging technologies in general, then examine two J2EE-specific technologies: Java Message Service and message-driven beans.
6.2.2.1. Overview of Messaging Technologies
Prior to the advent of Web services, developers often chose messaging systems (called MOM for Message Oriented Middleware) to create an integration architecture. With a messaging system, two systems can communicate with each other by sending messages. Such messages, which are delivered asynchronously, typically consist of two parts: one part—the message body—contains the business data and the other part—the message header—contains routing information. Since messages are sent asynchronously, the sender does not have to wait for the message to be delivered to the receiver.
There are two common messaging styles: point-to-point, and publish and subscribe. A point-to-point messaging style is used when messages are sent to only one receiver. The recipient receives messages sent to it through a queue specifically set up for the receiver. A message sender sends messages to this queue, and the recipient retrieves (and removes) its messages from the queue. Publish and subscribe, on the other hand, is intended to be used when there can be multiple recipients of a message. Rather than a queue, this style uses a topic. Messages are sent—or, more correctly, published—to the topic, and all receivers interested in these messages subscribe to the topic. Any message published to a topic can be received by any receiver that has subscribed to the topic. See Figure 6.2.
In addition, a typical MOM system has a message router that is responsible for ensuring message delivery (according to the agreed-upon quality of service) to the receiver. The message router uses the message header information to determine where and how to route the message contents.
When used for integration, an enterprise very likely requires that all participating EIS systems communicate with each other by sending messages via the messaging system. As a result, enterprises typically standardize on one vendor for their MOM system, and they use that vendor's adapters to accommodate their various EISs. In return, enterprises using messaging systems gain the benefits of asynchronous messaging calls: Messages are queued and delivered when the target system is available without constraining the sending system. The asynchronicity of messaging systems means that communicating applications need not be currently running to receive messages. This protects the communicating applications from system failures and other types of partial outages, conditions that are not uncommon in network situations.
Messaging systems also bring a dynamic quality to EIS systems. Components can be added or removed to the network without affecting other systems. Systems do not need to have their throughputs perfectly match since they can interact with the messaging system at their own pace. For example, if one application sends messages more rapidly than the receiving application can retrieve these messages, the messaging system keeps these messages in the queue indefinitely. As a result, good overall throughput is achieved since each part of the system can work at its optimum capacity.
Furthermore, messaging technology is considered a fairly mature technology. Most MOM systems provide a number of quality of service features, such as reliable once and only once delivery, load balancing, scalability, fault tolerance, and transactional support.
However, the proprietary nature of MOM systems results in some significant disadvantages. Since they use proprietary protocols over the network, it is usually more difficult to mix and match MOM products from different vendors. Although messaging systems decouple the sender and receiver and permit communicating parties to run on different hardware and software platforms, they fall short of achieving true interoperability because they tie developers to their proprietary APIs to send and receive messages. As a result, application developers must customize their applications for different MOM systems.
6.2.2.2. Java Message Service
The Java Message Service (JMS) API, a standard Java API defined for enterprise messaging systems, 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.
For the J2EE 1.4 platform, JMS includes some enhancements. In particular, the addition of common interfaces enables you to use the JMS API so that it is not specific to either a point-to-point or publish-subscribe domain. A JMS provider may also use the J2EE Connector architecture to integrate more closely with an application server. (The section “EIS Access Technologies” on page 259 discusses the J2EE Connector architecture.)
In many ways, JMS is to messaging systems what JDBC is to database systems. Just as JDBC provides a standard interface to many database systems, JMS provides a standard API for MOM systems. In fact, JMS changed the proprietary nature of MOM systems by providing a standard Java API that interfaces with any MOM system. The developer now writes to this standard API rather than to individual, proprietary APIs. The J2EE platform further simplified—and made more portable—the integration of a MOM system with a J2EE application server.
Similar to its support for JDBC, the J2EE platform has added support to JMS for a connection-oriented operational style: Developers can look up a factory and a connection in the same way. Like JDBC, JMS supports transactions and can continue JTA transactions started by either a Web or EJB component.
6.2.2.3. Message-Driven Beans
Message-driven beans, which are EJB components that receive incoming enterprise messages from a messaging provider, contain the logic for processing these messages. The business logic of a message-driven bean—which may include initiating a workflow, performing a computation, or sending a message—may be driven by the contents of the message itself or merely the receipt of the message.
Message-driven beans are particularly useful in situations where messages need to be automatically delivered and asynchronous messaging is desired. They enable applications to be integrated in a loosely coupled, but still reliable, fashion. Message-driven beans are also useful when the delivery of a message should be the event initiating a workflow process or when a specific message must trigger a subsequent action.
When an application produces and sends a message to a particular message destination queue or topic, the EJB container activates the corresponding message-driven bean (from the pool of available message-driven beans). The activated bean instance consumes the message from the message destination. Since they are stateless, any instance of a matching type of message-driven bean can handle the message.
Implementing a message-driven bean is straightforward. The bean developer extends the javax.ejb.MessageDrivenBean interface and a message listener interface for the bean—the message listener interface corresponds to the enterprise's messaging system. For enterprises using JMS, the developer extends the javax.jms.MessageListener interface. A developer may embed business logic to handle particular messages within the MessageListener methods. For example, when a message-driven bean consumes JMS messages, the developer codes the message-handling business logic within the onMessage method. When a message appropriate for this bean arrives at a message destination, the EJB container invokes the message-driven bean's onMessage method.
With message-driven beans, you can make the invocation of the bean part of a transaction. That is, you can ensure that the message delivery from the message destination to the message-driven bean is part of any subsequent transactional work initiated by the bean's logic. If problems occur with the subsequent logic causing the transaction to roll back, the message delivery also rolls back—and the message is redelivered to another message-driven bean instance.
6.2.3. EIS Access Technologies
The J2EE 1.4 platform includes the J2EE Connector architecture, a technology designed specifically for accessing enterprise information systems (EISs). The Connector architecture simplifies integrating diverse EISs into the platform, since each EIS can use the same, single resource adapter to integrate with all compliant J2EE servers.
The J2EE Connector architecture provides a standard architecture for integrating J2EE applications with existing EISs and applications, and particularly for data integration with non-relational databases. The Connector architecture enables adapters for external EISs to be plugged into the J2EE application server. Enterprise applications can use these adapters to support and manage secure, transactional, and scalable, bi-directional communication with EISs. The EIS vendor knows that its adapter will work with all J2EE-compliant application servers, and the compliant J2EE server can connect to multiple EISs. See Figure 6.3.
The earlier version of the Connector architecture focused on synchronous integration with EISs, while the current version that is part of J2EE 1.4 extends this core functionality to support asynchronous integration. That is, it supports both outbound and inbound message-driven integration that is protocol independent.
A resource adapter is a J2EE component that implements the Connector API for a specific EIS. Communication between a J2EE application and an EIS occurs through this resource adapter. In a sense, think of a resource adapter as analogous to a JDBC driver, since it provides a standard API for access between the J2EE server and the external resource.
The J2EE Connector architecture, through its contracts, establishes a set of rules for EIS integration. The J2EE application server and an EIS resource adapter collaborate, through a set of system-level contracts, to keep security, transaction, and connection mechanisms transparent to the application components. Application components and resource adapters rely on the application-level contract for their communication.
The application-level contract defines the API used by a client to access a resource adapter for an EIS. This API may be the Common Client Interface (CCI), which is a generic API for accessing multiple heterogeneous EISs, or it may be a resource adapter-specific API.
The initial release of the Connector architecture, which is part of the J2EE 1.3 platform, established three system-level contracts, as follows:
Connection management contract— Supports connection pooling to an underlying EIS, an important requirement for scalable applications.
Transaction management contract— Supports local and global transactions, and enables management of (global) transactions across multiple EISs.
Security management contract— Enables secure interchanges between an EIS and a J2EE application server and protects EIS-managed resources.
The most recent release (version 1.5) of the Connector architecture expanded the capabilities of resource adapters. This release expanded the transaction support for a resource adapter. Previously, a transaction had to start from an enterprise bean on the J2EE application server, and it remained in force during operations on the EIS. Now, transactions can start on the EIS and be imported to the application server. The J2EE Connector architecture specifies how to propagate the transaction context from the EIS to the application server. The Connector architecture also specifies the container's role in completing a transaction and how it should handle data recovery after a crash.
The current version also specifies additional system-level contracts to the initial three contracts just noted. These new contracts are:
Messaging “pluggability” contract— Extends the capabilities of message-driven beans so that they can handle messages from any message provider rather than being limited to handling only JMS messages. By following the APIs for message handling and delivery specified in this contract, an EIS or message provider can plug its own custom or proprietary message provider into a J2EE container. JAXM is a good example of this type of message provider.
Work management contract— Enables the J2EE application server to manage threads for resource adapter, ensuring that resource adapters use threads properly. When a resource adapter improperly uses threads, such as when it creates too many threads or fails to release threads, it can cause problems for the entire application server environment. Poor thread handling by a resource adapter can inhibit server shutdown and impact performance. To alleviate this problem, the work management contract enables the application server to pool and reuse threads, similar to pooling and reusing connections.
In addition, the work management contract gives resource adapters more flexibility for using threads. The resource adapter can specify the execution context for a thread. The contract allows a requesting thread to block—stop its own execution—until a work thread completes. Or, a requesting thread can block while it waits to get a work thread; when the application server provides a work thread, both the requesting and work threads execute in parallel. Yet another option, a resource adapter can submit the work for the thread to a queue and have it execute at some later point; the adapter continues its own execution without waiting further. Thus, a resource adapter and a thread may execute in conjunction with each other or independently, using a listener mechanism, if need be, to notify the resource adapter that the work thread has completed.
Lifecycle management contract— Enables an application server to manage the lifecycle of a resource adapter. With this contract, the application server has a mechanism to bootstrap a resource adapter instance at deployment or at server startup, and to notify the adapter instance when it is undeployed or when the server is shutting down.
6.2.4. Web Service and XML Technologies
Although messaging systems provide many of the same EAI advantages as Web services, Web services go a step further. Principally, Web services support multiple vendors and the ability to go through firewalls using Internet standards. Web services also support a flexible XML format.
The J2EE 1.4 platform provides a rich set of Web service APIs and XML document-manipulating technologies. The Web service APIs—JAX-RPC, JAXR, SAAJ, JAXB, and JAXP—provide standard Java APIs for integrating applications and other systems. A Java application can use these APIs to obtain and use a Web service. These APIs are particularly useful when an application or system exposes a Web service layer explicitly for integration purposes.
There are also a number of XML-related APIs and facilities in the Java language (and the J2EE 1.4 platform) that can be applied to integration problems. They permit you to define an interface data model, manipulate disparate documents, and perform transformations between data types. These XML APIs give you the ability to structure a data model for passing data among different systems.
Chapter 2 discusses these technologies in greater depth.