The J2EE stack is composed of several containers, among which the JCA container. Not as popular as the EJB or Web containers, the JCA container is nevertheless a very important piece of the J2EE stack. This container contains the “glue” that provides transparent transactional connectivity to third-party system. Remember that from point of view of the Web and EJB containers, the database or the JMS brokers are third-party systems. So you probably already used JCA connectors without even noticing it.
A JCA connector is an adapter between the J2EE world and the outside world. The J2EE world is indeed a managed environment that provides many services such as transaction management, connection pooling, thread management, lifecycle events, configuration injection or declarative security. If you want to leverage these features while connecting to your third party system, JCA is the way to go.
Connectors are bi-directional. They can be used to connector to the outside, or from the outside. In the later case, we speak about connection inflow. We will discuss here only the first case: outside connectivity.
Anatomy of a JCA connector
| Managed connection | A managed connection represents a physical connection to the third party system. Managed connections are pooled and are enlisted/delisted in the global transactions automatically by the application server. |
| Connection handle | The client (e.g.: EJB, or Servlet) does not manipulate the managed connection directly. It uses instead a connection handle which exposes only the subset of available operations that are relevant to a client; it is the client-side view of the managed connection.
Several handles can have the same underlying managed connection. This could happen for instance if the client obtains two connection handles for a given third party system while in the same transaction; the application server can optimize this case and re-use the same managed connection. |
| Connection request info | The information that identifies the target third party system (e.g.: database connection string). The connector’s connection pool can contain connections to different target systems. The connection request info must then be checked to ensure the connection targets the desired external system. |
| Managed connection factory | The managed connection factory has two purposes:
(1) Create brand new managed connection according to the desired connection request info (2) Check if some managed connection can be re-used according to a given connection request info. This is refereed as connection matching. The connection matching mechanism exists because the application server, which manages the connection pool, is not able to know to which target system a given connection points to. This is part of the connector’s logic. |
| Connection factory | The client (e.g.: EJB, or Servlet) does not manipulate the managed connection factory directly. It uses instead a connection factory which is a façade that shields the client from the connector’s internal complexity. The connection factory typically contains a single method getConnection(…) which returns a connection handle to the client. The connection factory will interact with the application server and the managed connection factory to implement connection pooling correctly. |
| XAResource | From the conceptual point of view, the managed connection is the participant that is enlisted/delisted in the global transaction. However, the managed connection is not forced to implement the XAResource interface itself, but only to expose a method getXAResource(…). An auxiliary object can then be returned that will act as an adapter between the JTA transaction manager and the managed connection. |
Below is the component view:
A complete sequence diagram
The various elements of a JCA connectors have now been presented. Below is the outline of a call to the Connection Factory’s getConnection() method.
| 1 | Client creates the connection request info of the external system |
| 3 | Client calls getConnection( requestInfo) on the ConnectionFactory |
| 3.1 | ConnectionFactory calls allocateConnection( managedConnectionFactory, requestInfo) on the application server. The applicaton server exposes its functionalities through in the ConnectionManager interface. Connectors can therefore be implemented in a standard way without knowing the application server implementation. |
| 3.1.1 | The application server gathers a list of available (free) managed connection in the pool.Because the application server doesn’t know which managed connection points to the desired system, it calls matchConnection( listOfFreeConnection, requestInfo) on the managed connection factory.
The managed connection factory check if any of the provided connection indeed corresponds to the given request info. If there are none, it returns null. |
| 3.1.3 | No managed connection is available, or none of them match the request info. The application server need to allocate a new connection and calls createManagedConnection( requestInfo ) on the managed connection factory. |
| 3.1.3.1 | The managed connection factory creates a brand new managed connection and return it. |
| 3.1.5 | The application server gets the XAResource which belongs to the managed connection and enlist the connection in the distributed transaction. The application server put the managed connection in the pool. |
| 3.2 | The application server returns the managed connection to the connection factory. |
| 3.3 | The connection factory calls getConnection() on the managed connection and obtains a connection handle. |
| 4 | The connection factory return the connection handle to the client. |
://ewernli 