Table of Contents
This chapter describes JCA standards and resource adapters.
Since J2EE 1.3 introduced JCA 1.0, JCA(Java EE Connector Architecture) has upgraded to JCA 1.5, which contains various types of extensible functions including inflow message management introduced in J2EE 1.4.
Currently, JCA 1.6 is the latest release, and it supports annotations for resource adapters and Security inflow.
The Connector Architecture is the standard defined for interoperating with the Enterprise Information System(EIS) including but not limited to Mainframe, ERP(Enterprise Resource Planning), TP Monitor, the legacy database systems. Without the standard, a separate custom driver needs to be implemented between each EIS and WAS (Web Application Server) vendors, resulting in a problem with N by M complexity. This will severely restrict the portability and extensibility of the Java EE environment.
To tackle such problem, the JCA standard introduces a concept of connector architecture and defines resource adapter needed for interoperation. If EIS vendors provide resource adapters, using the connector architecture, they can run on multiple WASs without code modification. Refer to "1.3. Resource Adapters and JDBC Driver" for more information about resource adapters.
Note
This guide does not cover information about the connector architecture. Refer to related documents or JCA 1.6 standards for more information.
There are two kinds of connector architectures; outbound and inbound. 'Out' and 'in' refer to communication direction between WAS and EIS.
In the connector architecture, the roles of WAS and resource adapter for outbound and inbound communications is defined.
A term that represents the outbound architecture is 'connection'. Applications running on WAS create connections to send requests and receive results.
A typical example is sending SQL from servlet or EJB component to the database. In the figure, [Figure 1.1], outbound corresponds to the flow of a request from Session Beans or Entity Beans to the EIS through the resource adapter.
JEUS provides the following for efficient management of connections.
-
Connection Pool
-
Enhances the performance efficiency by reusing connections without creating a new connection each time.
-
Keeps the number of requests from WAS to resources from increasing infinitely when the load is heavy.
-
-
Transaction Management
-
Automatically connects with the transaction manager if a global transaction(XA) is needed.
-
Supports connection sharing for global transactions(XA).
-
Besides what is mentioned, JEUS also provides additional functionalities. For other functions of outbound, refer to "Chapter 2. Outbound Management".
The JCA standard defines a mechanism for interoperating with various kinds of message-oriented services including JMS. In the mechanism, a resource adapter plays the role of the message provider, and an end-point application that of the message consumer. The type of a transmitted message has no relationship with WAS, and the resource adapter can arbitrarily decide on a message interface that defines a method for the actual transmission of the messages.
The following figure shows the message inflow.
A message provider sends a message only by a direct request
from a message consumer. No context is transmitted and shared between
them. In order to send information related to a transaction that
occurred in EIS or authentication to WAS, it is necessary to transmit
the context through the Work Manager.
For details about inbound communication management of JEUS, refer to "Chapter 3. Inbound Management" or "3.2. Message Inflow".
Note
For details about context transmission, refer to the JCA standards.
Work Manager
A resource adapter processing outbound messages does not require a thread, but the one processing inbound messages may require a thread. The JCA standard recommends using a WAS-provided Work Manager instead of creating a Java thread. In particular, the Work Manager must be used to interoperate with a transaction that started in EIS or with authentication related information.
The implementation entity of JEUS Work Manager is based on the thread pool. If a resource adapter sends a Work Instance, the thread pool obtains a worker thread to process the instance. The resource adapter can send an event listener to the worker thread to receive the start and end process events and exception occurrences. It can also send the required transaction and authentication information as a context.
For more information about the implementation entity of JEUS Work Manager, refer to "3.1. Work Manager Management". For basic concept about Work Manager, see the JCA standards.
While JDBC defines a standard for the interoperation with relational database(RDB), resource adapter defines standard for multiple information systems including RDB. The resource adapter defines WAS-interoperable external resources more generally and widely than the JDBC driver.
The big difference between a resource adapter and a JDBC driver is that the resource adapter is defined in the Java EE standard, while the JDBC driver is built based on the Java SE standard. Therefore, the JDBC driver can be used by a stand-alone Java application.
A JDBC driver uses the system classpath of a jar file, and to update the driver currently running JVM needs to be shut down. The resource adapter, on the other had, is an application defined by Java EE, it can be packaged into a rar file and deployed to WAS.
To update the version of a resource adapter, redeploy it without terminating WAS. It is also possible, like the JDBC driver, to convert the adapter into a jar file and configure it using the system classpath, but in general, a resource adapter is a Java EE application that can be redeployed.
The following table compares resource adapters to JDBC drivers.
| Resource Adapter | JDBC Driver | |
|---|---|---|
| Concept | Defined in the Java EE standard. | Java SE concept. (JDBC driver can be used directly in a stand-alone Java application.) |
| Interoperation | Defines a standard for interoperation with several information systems including relational database(RDB). | Defines a standard for communication with relational database(RDB). |
| Deployment | Can be packaged into a rar file, and deployed to WAS. | Uses system classpath of a jar file. |
| Update | Redeployment without terminating WAS. | For an update, shut down the running JVM. |
Compared to the JDBC driver, the resource adapter, defined more generally and widely, can be used more easily.
CCI(Common Client Interface) provides outbound resource adapter as an integrated API. The JCA standard recommends using CCI when developing a resource adapter.
CCI conceptualizes a service call as an interaction, and abstracts the service method as an instance dependent on an EIS called interaction Spec. Arguments and returned values of the call is provided in the form of a record.
In general, it is recommended to include the FunctionName and InteractionVerb in the interaction specification. CCI supports three types of services -synchronized transmission, synchronized reception, and synchronized transmission and reception, but does not support asynchronized services.
Caution
CCI is derived from an intent to define a standard interface between an application and a resource adapter. In general, WAS is not involved with the workings of the interface between an application and resource adapter, but considers it as a java.lang.Object type.
The following is the preparation steps for calling an EIS service using CCI.
// get Connection to EIS by lookup ConnectionFacotry in JNDI
javax.naming.Context nc = new InitialContext();
javax.resource.cci.ConnectionFactory cf = (ConnectionFactory)nc.lookup("java:/comp/env/eis/ConnectionFactory");
javax.resource.cci.Connection cx = cf.getConnection();
// create Interaction
javax.resource.cci.Interaction ix = cx.createInteraction();
// create Interaction Spec
com.wombat.cci.InteractionSpecImpl spec = .....
spec.setFunctionName(“<EIS_FUNCTION_NAME>”);
spec.setInteractionVerb(InteractionSpec.SYNC_SEND_RECEIVE)”
. . .
Data needed for the service is saved as a record, and the service is called as follows:
// call EIS service boolean ret = ix.execute(spec, input, output);
Note
For details about CCI, refer to the JCA standard or CCI related documents.