Since J2EE 1.3 introduced Java EE Connector Architecture (JCA) 1.0, JCA 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.7 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 the mainframe, Enterprise Resource Planning (ERP), TP Monitor, and the legacy database systems. Without the standard, a separate custom driver needs to be implemented between each EIS and Web Application Server (WAS) 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. For more information about resource adapters, refer to "1.3. Resource Adapters and JDBC Driver".

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.

[Figure 1.1] Overview of the Connector Architecture

1.2.2. Inbound

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.

[Figure 1.2] Inbound 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. Managing the Work Manager". 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 an 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.

Compared to the JDBC driver, the resource adapter, defined more generally and widely, can be used more easily.

Common Client Interface (CCI) 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.

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)”
. . .

The data that the EIS service needs is saved as a record, and the service is called as follows:

// call EIS service
boolean ret = ix.execute(spec, input, output);