| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
The EIS integration approaches may be classified as shown in Figure 6.5.
- Data integration using the JDBC API (for relational databases) or Connector architecture (for non-relational databases)
- Asynchronous, message-based, loosely-coupled integration using the JMS and J2EE Connector architecture
- Synchronous, tightly-coupled integration using the Connector architecture
- Legacy connectivity using the Connector architecture
This mode of integration involves synchronous communication between J2EE applications and the target EIS. Synchronous communication between a J2EE application and an EIS follows the request-response interaction model. An application initiates a request to the target EIS. The application then blocks its processing in the request invocation thread while it waits for a response from the EIS. The application continues its execution after it receives the response.
Most EISs utilize a synchronous request-reply interaction model. Typically, an EIS defines an API for remote function calls that applications use to issue synchronous requests to the EIS. For example, an EIS might define an API that includes a remote function to create an account receivable item in the EIS. An enterprise application invokes this remote function on the EIS to create an account receivable item and waits until it receives a reply containing the results of the function's execution on the EIS. This interaction is synchronous because the calling application's invocation thread waits synchronously while the function executes on the EIS and continues when the remote function returns.
The 1.0 version of the Connector architecture supports a synchronous request-response interaction mode where an application component initiates the synchronous request. The application server and resource adapter for the underlying EIS manage transaction and security through the system contracts provided in this synchronous request-response interaction mode. The resource adapter takes the responsibility to propagate the security and transaction context to its underlying EIS using an EIS-specific communication protocol.
Synchronous interaction leads to tight coupling between a J2EE application and an EIS. You should consider the implications of this when integrating applications with EISs. Consider a typical scenario where a J2EE application needs to access an EIS to process client-initiated requests. The application itself may be designed to handle multiple concurrent client requests. It may employ either a multithreaded implementation or multiple application instances may be running on multiple application server processes. When an application instance receives a client request, it synchronously invokes an EIS function. The invocation thread in the application process is then blocked from further processing until it receives a reply from the target EIS.
Suppose that the target EIS has a limited load capacity; that is, the EIS is capable of handling only a limited number of concurrent requests on a limited number of connections. As a result, the EIS is unable to process the same number of concurrent requests as the application. In a tightly-coupled synchronous integration, the application's response time and throughput for client requests may drop since it must wait for synchronous invocations on the EIS to complete.
Synchronous remote function calls typically expose underlying distribution and transaction management mechanisms, which may be vendor specific or based on a middleware standard. When these mechanisms are exposed, the application may become tightly coupled to the middleware mechanisms for transactions, distribution, and security. This causes problems if the application needs to integrate with other types of EISs, because its communication model must be redesigned to handle different middleware mechanisms.
The tight coupling that results from synchronous communication also raises issues about the relationship between an application and an EIS. The dependency between the two may cause the application's performance to be impeded by communication failures. For example, if the EIS is down or unavailable, an application request may return immediately with an error. The application logic needs to include code to initiate retries of such failed requests, or the EIS may successfully execute a request but be unable to reply because of a communications failure after the request was received. To handle this, the application logic must include timeouts or it will hang indefinitely waiting for a response.
Asynchronous integration involves message-based communication between a J2EE application and EIS. An application sends a request to an EIS. The request sender continues its own processing--that is, the application's thread does not block--while the EIS handles the request asynchronously. The request sender does not have to wait for the EIS processing to complete and for the reply to come back. Instead, the thread sends the message and continues processing client requests.
There are two forms of asynchronous message-based communication: queue-based communication and publish-subscribe messaging. Queue-based communication, or point-to-point messaging, involves a message queue that is independent of both sending and receiving applications. The message queue acts as a message buffer between the communicating applications. The sender application sends a message to this queue, while the receiver application receives its messages from the queue.
With a publish-subscribe messaging mechanism, an application publishes messages on a specific topic. Multiple applications, called subscribers, can subscribe to this topic and receive the published messages. The publish-subscribe facility manages delivery of published messages to applications subscribing to the topic.
Regardless of the messaging communication, a message represents structured data exchanged through asynchronous message-based communication. A message carries information used within a single enterprise's business processes or across the business processes of multiple enterprises. For example, a message can represent information required to invoke an EIS function. Another message can carry the returned value of this function invocation.
When using asynchronous communication, an application and an EIS are said to be loosely coupled. With loose coupling, an application thread can continue processing client requests without blocking on EIS performance or communication glitches. The application is not bound to the EIS or the communication delivery mechanism.
An enterprise messaging system may support both publish-subscribe and queue-based messaging, as well as the following services:
- Message routing--A messaging system processes and routes messages to one or more peer applications. The messaging system uses the routing information carried within a message.
- Transaction management--A messaging system can act as a transactional resource manager, allowing a client application to use a transaction model to interact with the messaging system. For example, a client application can produce a set of messages and use a transaction to group the messages together into a single atomic unit of work. When the transaction commits, the messaging system sends the set of messages as one unit. If the transaction rolls back, the messaging system discards the entire set of messages produced within the rolled back transaction.
- Reliable message delivery--A messaging system can provide different levels of message delivery semantics, from making an attempt to deliver the message (called at-most-once delivery) to guaranteeing that the message is delivered (called exactly-once delivery).
- Message priority and ordering--A messaging system can permit applications to assign priorities to messages and to indicate that messages should be delivered in serial order. The messaging system delivers messages assigned a higher priority ahead of those assigned a lower priority.
- Message transformation--Advanced messaging systems support message transformation and the use of rules engines. When a message flows through such a messaging system, it may be transformed based on the system's configured set of rules and defined message schemas. For example, the messaging system may transform the format of a particular message to one that is better understood by the intended consumer. The message system first transforms the message, then routes the message to the appropriate consumer application.
When designing your application, you need to decide whether to use synchronous or asynchronous integration with its target EISes and existing applications. Both synchronous and asynchronous integration approaches are valid for application integration, and the choice should be based on the integration requirements and use cases. Base your decision on the following guidelines.
- Quality of services required--The use of a queue or a publish-subscribe system provides higher quality of services, such as message routing and reliable message delivery, than synchronous communications.
- Application throughput--Asynchronous messaging can lead to better throughput because a queue buffers messages, supports message routing, and guarantees message delivery.
- Transactional integration--A synchronous communication model is more suitable when an application needs to perform secure and transactional access to one or more EISes synchronously for client request processing. In such cases an application can afford the overhead of tighter coupling with an EIS to ensure higher quality request processing and error handling.
- Programming model complexity--An asynchronous communication programming model is more complex than the more common synchronous request-response model. While the asynchronous model provides more services, the cost is greater application complexity and more work on the part of developers.
A J2EE application developed using the J2EE component model may need to integrate with existing data. The existing data may be relational, object-based, hierarchical, or some legacy representation. The problem is magnified when the existing data is huge (such as millions of records) and the schema is complex. Often, it's not possible to change the database schema because other applications depend on it.
The JDBC API is recommended for integration with relational databases. This book does not provide a primer for JDBC since there are numerous other sources to learn about JDBC. (See "References and Resources" on page 200.) Instead, this chapter focuses on J2EE application design issues related to database access.
For non-relational and legacy databases, the J2EE Connector architecture defines a simple tool-focused Common Client Interface (CCI) API that resource adapters can implement. (Note that Connector architecture does not require CCI, but recommends it for toolability.) CCI provides a remote function call API that can be used to develop or generate higher-level abstractions to simplify access to the underlying EISs.
Data integration can be handled on two levels:
- Model a J2EE application using the EJB programming model. Use entity beans and stateful and stateless session beans to partition a J2EE application. Develop the EJB components and then map them to the existing schema. Whenever possible, use EJB container-managed persistence. See Chapter 5.
- Develop or generate abstractions (called access objects) that represent the underlying existing data and stored procedures. These abstractions bridge the gap between the EJB components and the existing data. See Section 6.4.3 on page 188.