The ability of applications to interface with resources outside of the application server process and to use those resources efficiently has always been an important requirement. Equally important is the ability for vendors to plug in their own solutions for connecting to and using their resources.

An application might require access to many types of resources, which may or may not be located in the same machine as the application. Therefore, access to a resource begins with a connection that is a pathway from an application to a resource, which might be another transaction manager or database manager.

Java™ program access to a broad range of back-end resources is performed through a resource adapter. This is a system-level software driver that plugs into an application server and enables a Java application to connect to various back-end resources.

The following considerations are common to all connections:

• Creating a connection can be expensive. Setting up a connection can take a long time when compared to the amount of time the connection is actually used.
• Connections must be secure. This is often a joint effort between the application and the server working with the resource.
• Connections must perform well. Performance can be critical to the success of an application, and it is a function of the application's overall performance.
• Connections must be monitorable and have good diagnostics. The quality of the diagnostics for a connection depends on the information regarding the status of the server and the resource.
• Methods for connecting to and working with a resource. Different database architectures require different means for access from an application server.
• Quality of service, which becomes a factor when accessing resources outside of the application server. The application might require the ACID (Atomicity, Consistency, Isolation, and Durability) properties that can be obtained when using data in managing a transaction.

Enterprise resources are often older resources that were developed over time by a business and are external to the application server process. Each type of resource has its own connection protocol and proprietary set of interfaces to the resource. Therefore, the resource has to be adapted in order for it to be accessible from a JVM process as contained in an application server.

WebSphere® Application Server has facilities to interface with other z/OS® subsystems such as CICS®, DB2® and IMS™. This is done through a resource adapter and a connector. Accessing back-end Enterprise Information Systems (EIS) extends the functionality of the application server into existing business functions, providing enhanced capabilities.

The J2EE Connector Architecture defines the contracts between the application, the connector, and the application server where the application is deployed. The application has a component called the resource adapter. This is contained within the application code handling the interface to the connector which the application developer creates.

From a programming perspective, this means that programmers can use a single unified interface to obtain data from the EIS. The resource adapter will sort out the different elements and provide a programming model that is independent of the actual EIS behavior and communication requirements.

Figure 1. Basic architecture of a connector to an EIS

Java Connector Architecture (JCA) is a standard that provides a uniform method for talking to different kinds of EIS systems from an application server. JCA is designed to facilitate sharing of data and to integrate new J2EE applications with legacy or other heterogeneous systems.

WebSphere for z/OS supports any JCA-compliant resource adapters, but does not provide any of its own, with the exceptions of the built-in JMS adapter, and the relational resource adapter for database management systems, such as DB2.