J2EE Connector Architecture(JCA), An Introduction

Introduction

JCA, the J2EE Connector Architecture, is an initiative towards EAI, Enterprise Application Integration. It is a standardized architecture providing the J2EE Components to have plug and play access to heterogeneous EIS, Enterprise Information Systems. Examples of EIS are ERP (Enterprise Resource Planning), Transaction Processing Systems, Legacy Database Systems etc. In the following section we will discuss about the major problems that the programmers had to face for the EIS Integration and the role of JCA.

• JCA Introduction
• Packaging and Deploying a Resource Adapter

EIS Integration

An Enterprise Information System provides the information infrastructure for an enterprise. This information may be in the form of records in the database, business objects in an ERP, a workflow object in a Customer Relationship Management (CRM) System or a transaction program in a transaction processing application. Prior to the Internet economy, many companies had heavily invested in Business and Management Information Applications Systems.

Examples of such systems can be:-

1. ERP, Enterprise Resource Planning applications, such as SAP, BAAN etc.

2. CRM, Customer Relationship Management applications, such as Seibel and Clarify.

3. Database applications such as DB2 and Sybase.

4. Main Transaction processing applications, such as CICS.

5. Legacy Database Systems such as IBM’s IMS.

Before the JCA, most vendors supported a variety of custom adapters for integrating their EIS. Basically these adapters provided custom native interfaces, which were complex to incorporate and limited to only one EIS. Because of this the application programmers had to deal with as many adapters as the number of EIS their application communicates to. Some of the limitations are listed below:-

1. Application programming for the EIS was proprietary in nature, because there was no generic platform for integration with the open architectures.

2. Custom adapters lacked support for Connection Management, which is very crucial for large scale Web Applications, where thousands of customers interact every second. Because of which programmers had to implement connection pooling in their code which is a shear waste of time and money of the enterprises.

3. There was no standard infrastructure solution available to provide a vendor-neutral Security Mechanism and Generic Transaction Mechanism support to multiple EIS resource managers.

In order to address the above problems Sun Microsystems released the J2EE Connector Architecture, JCA that provides a standard architecture for integration of J2EE Servers with heterogeneous EIS resources. It provides a common API and a common set of services within a consistent J2EE Environment.
The following diagram shows the J2EE application server with the JCA Components and some Enterprise Information Systems:-

In the above diagram, there is a Web Container and an EJB Container in the J2EE Application Server. There are also some blocks for Resource Adapters. Resource adapters play the role of intermediaries between the J2EE Application / Web Components and the EIS. The programmers communicate with the Resource Adapters using the CCI API, Common Client Interface API. This is very similar to the JDBC API where the J2EE Components communicate with the relational database drivers using the JDBC API.

In this architecture, the J2EE Application Server implements the JCA Services like Connection Management, Transaction Management and Security Management etc. Whereas the EIS vendors implements the Resource Adapters specific to their products. This way the programmers need to code their programs in vendor neutral manner to communicate with heterogeneous EIS resources from different vendors.

Elements of the J2EE Connector Architecture

The JCA is implemented by J2EE compliant Application Servers and the Resource Adapters are provided by the EIS vendors.
The Resource Adapter is an EIS specific, pluggable J2EE Component in the Application Server, which provides an interface for the J2EE Components to communicate with the underlying EIS.

There are the following elements and Services in a JCA implementation:-

1. System-level Services: - It defines the standard interface between the J2EE Components and the J2EE Aplication Server provider and the EIS Vendor. This contract specifies the roles and responsibilities of the Resource Adapter and the Application Server, so that they can co-ordinate with each other for the System level services like Connection Pooling, Security and Transactions. Furthermore this allows for any JCA compliant Resource Adapter to be pluggable to any J2EE Compliant Application Server.

2. CCI, Common Client Interface: - This is an API which is used by the J2EE Components and other non managed Java Applications (like standalone Java programs and Java Applets) to communicate with the Resource Adapters, which in turn communicate to the underlying EIS.

3. Packaging and Deployment Interfaces: - Packaging and Deployment Interfaces allow the Resource Adapters to be able to plug into any Application Server.

The following diagram shows all the components of the J2EE Connector Architecture. It shows how the components communicate with each other.

The CCI, Common Client Interface is part of the implementation of the Resource Adapters. The J2EE components use this API in order to communicate with the underlying EIS resource. Because of the System Level contracts the J2EE Application Servers provide the services like Connection Pooling, Transaction Management and Security Management and the programmers can stay away from the implementation of these services.

There are two types of environments based on the type of client application using the Resource Adapter. These are: -

1. Managed Environment: - This includes the multi tired J2EE based Web Applications that may have several Web / Application Components communicating to the Resource Adapters. Such applications are called as the Managed Applications in the JCA context.

2. Non-Managed Environment: - In a two tired architecture, where the application client directly uses the application, the Resource Adapter provides the system level services to its clients. Such applications are referred as Non Managed applications.

Resource Adapter

The Resource Adapter is a component in the J2EE Connector Architecture that sits between the J2EE Components and the EIS. This module is implemented with the EIS specific library, which can be written in Java or with native interface components. Basically it implements two things, first is the Common Client Interface, CCI so that when the developers invoke the methods of this library in their code, the invocations can be resolved by the implementations inside the Resource Adapter, and second is the implementation of the functionality through which it connects to the underlying EIS resource and get the work done for the method invocations. The Resource Adapters are required to support the System Level contracts as is required by the Application Servers. There are mainly two types of contracts that a Resource Adapter implements in order to get compliant with the JCA. These are: -

1. Application-Level Contracts: - Application Contract basically defines the CCI that the Resource Adapter must implement in order for the J2EE Components and the non-managed components to communicate to the underlying EIS resource.

2. System-Level Contracts: - This defines a set of System Contracts which enable the Resource Adapter to plug-in into the Application Server and utilize its services to manage connections, transactions and Security. The three basic contracts are discussed below: -

   1. Connection Management: - The Connection Management contract specifies the following things: -

      1. Connection to the Resource Adapters for managed and non-managed components can be made by using consistent application programming techniques, which remain same everytime.

      2. The Resource Adapter provides the Connection Factory and Connection Interface based on the CCI, which in turn is specific to the EIS.

      3. Provide a generic mechanism for the J2EE components to consume the Application Server services like Transaction, Security and last but not the least the Connection Pooling etc.

   2. Transaction Management: - This contract extends the Application Server's transactional capabilities to the underlying EIS Resource Managers. An EIS Resource Manager manages a set of shared EIS resources to participate in a transaction. It can manage the following two types of transactions: -

      1. XA Transaction: - XA Transactions are controlled and coordinated by external Transaction Managers. A JTA XATransaction Management contract exists between the JCA compliant Resource Adapters and its underlying Resource Manager. The participating EIS resource also supports XA Transactions by implementing an XAResource in their Resource Adapter. The JTA XAResource interface enables two resource managers to participate in transactions coordinated by an external Transaction Manager. This allows the transactions to be managed by a transaction manager which is external to the Resource Adapter.

      2. Local Transactions: - These transactions do not require any external Transaction Manager, because it is managed internally, either by the J2EE Application Server (container managed) or by the J2EE component (component managed). In Component Managed Transactions the component uses JTA UserTransaction interface or a transaction API specific to the EIS. When an application component requires an EIS Connection, the Application Server starts a local transaction using the currently available transaction context. Upon closure of the connection by the application component, the server commits or rolls back depending upon success or failure of the transaction.

   3. Security Management: - This contract defines ways to implement security between the Application Server and the EIS resource. There are the following mechanisms used to protect the EIS against unauthorized access and other security threats: -

      1. Use of user identification, authentication and authorization.

      2. Use of open network communication security protocols like Kerberos which provide end to end security with authentication and confidentiality services.

      3. Implementing an EIS specific security Service.

EIS Sign-On

A Sign-on process is required while creating a new connection to EIS. Based on the security context, authentication and authorization is done for the user to obtain appropriate access. A re-authentication is required in case the Security Context is changed for the user. The following steps are required for sign on: -

1. Identity of the initiating user, or Resource Principal, is determined. This helps finding the security context of the user using which the connection will be established to the EIS.
   
2. Resource Principal is authenticated if the connection is not already authenticated.
   
3. Establish a secure connection between the Application Server and the EIS Resource using secure mechanisms like SSL or Kerberos etc. At this point the connection is associated with the initiating user. All subsequent invocations will happen under this context.
   

This sign-on process can be Application Managed or it can be Container Managed. In case of Application Managed sign-on process, the application component itself provides the security credentials to the EIS Resource Adapter. While in the later case it becomes the duty of the application to find out the Resource Principal of the initiating user and present information of this Resource Principal to the EIS Resource Adapter in the form specific to the JAAS, Java Authentication and Authorization Service.