Microsoft .NET and J2EE Interoperability Toolkit (Pro-Developer)

This brief overview provides basic information about the Java Connector Architecture (JCA). It explains how JCA makes the process of accessing and integrating disparate information systems much easier. One of the goals of the new J2EE connector architecture is to bring Enterprise Application Integration (EAI) into mainstream use. Although full coverage of this technology is beyond the scope of this book, the goal is to inform the reader about the JCA technology and the benefits derived from using connectors to access an Enterprise Information System (EIS).

Components of the JCA

The finalized JCA specification, version 1.5, released on October 31, 2002, provides a convenient mechanism for storing and retrieving enterprise data in J2EE. Examples of EISs include ERP (Enterprise Resource Planning), mainframe transaction processing, and database systems. The connector architecture also defines a Common Client Interface (CCI) for EISs access. The CCI defines a client API for interacting with disparate systems.

The connector architecture allows integration between J2EE servers and EISs. The architecture consists of two parts:

• An EIS vendor-provided resource adapter and an application server, such as BEA’s WebLogic, that permits the adapter to plug into it.

• A set of three contracts that provide connection management, support transactions, and security. The contracts offer bidirectional communications (inbound and outbound) between an application server and an EIS, courtesy of a resource adapter.

Connection Management Contracts

A connection-level contract provides the agreement that a J2EE container must have with an adapter and refers to establishing, pooling, and destroying connections. In addition, the contract allows interested listeners to respond to events such as error handling.

All JCA resource adapters must provide two implementations with the adapter. First, a ConnectionFactor offers a vehicle for creating connections. Second, the Connection class represents the specified resource adapter’s connection.

Transaction Management Contract

The transaction management contract manages transactions in two different ways. First, it permits distributed transactions to propagate transactions that begin from inside the application server to an EIS. Second, the transaction management contract can control transactions by creating local transactions as well.

Security Contract

The security contract allows the application server to connect to an EIS by employing security properties. The server authentication process consists of a user ID and a password or certificate. The application server can use two methods to authenticate to an EIS: component-managed sign-on and container-managed sign-on.

The most efficient method of configuring security properties is using component-managed sign-on. This permits the developer to pass security properties every time a connection is acquired from the resource adapter. In the second method, container-managed sign-on, the security credentials configure when the resource adapter is deployed on the application server. Several different options are available for configuring security properties when using the container-managed sign-on procedure:

• Configured Identity All resource adapters use the same identity when connecting to the EIS.

• Principal Mapping This is the principal used when connecting to the EIS. It is based on a combination of the current principal in the application server and the actual mapping.

• Caller Impersonation The principal in the EIS must match the principal in the application server.

• Credentials Mapping This is similar to Caller Impersonation—the type of credentials are mapped from the application server credentials to EIS credentials.

Exploring the Common Client Interface

It is possible to employ JCA’s Common Client Interface methodology, representing functionality similar to employing JDBC to invoke remote procedures. CCI APIs are divided into four sections:

• Connection interfaces

• Interaction interfaces

• Record/ResultSet interfaces

• Metadata interfaces

Connection interfaces refer to APIs used to establish a connection to an EIS. Interaction interfaces are related to command execution on an EIS. The Record/ ResultSet interfaces encapsulate query results to an EIS. Metadata interfaces permit the querying of EIS data types.

It is significant that most recent releases of application servers, including IBM’s WebSphere application server, version 5.0, and BEA’s WebLogic application server, support JCA adapters for enterprise connectivity. Using JCA for access to an Enterprise Information System is similar to using JDBC (Java Database Connectivity) to access a relational database or other type of repository.

Before the emergence of JCAs, individual EAI vendors found it necessary to create a proprietary resource adapter interface for their own EAI product. This means the vendor’s product required the development of a resource adapter for each EAI vendor and EIS combination. To solve that cumbersome requirement, JCA provides a way of standardizing all resource adapter interfaces.

Understanding the Role of a Resource Adapter

What is a resource adapter? A resource adapter is a system-level library used by an application server or a client to connect to a resource manager. The resource adapter may also provide additional services beyond the connection API. The resource adapter plugs into an application server and facilitates connectivity between the EIS, the application server, and the enterprise application itself. The application server extends its system to support the connector architecture. This ensures connectivity to multiple EISs. In addition, the resource adapter plugs into any application server that supports the JCA.

The next question naturally follows: what role does the resource manager play? It provides access to an identified collection of shared resources. The resource manager is an active participant in a transaction.

Data Mapping

Data mapping is easy to understand. It simply means data retrieved from a resource, such as a relational database or similar repository (this could also include Microsoft’s Active Directory), and acquired in one format or another. The data requires restructuring in a format based on a business object’s need. For example, let’s assume the data retrieved exists in PDF format and needs transformation into XML. In order to achieve document restructuring, XML-based technologies such as XSLT exist precisely for this purpose.

It is always challenging to map data from one system to another because each business object must be mapped on both systems, an extremely time-consuming process. Fortunately, most EAI vendors provide tools to enable a developer to achieve mapping. The Enterprise JavaBeans Container Managed Persistence facility provides such mapping tools.

Understanding the Message Broker

Message brokers support both point-to-point and publish/subscribe messaging. In fact, many EAI products frequently use messaging as the connectivity layer to bind disparate systems together. A developer can implement some of a message broker’s features in an EAI product by employing Java Message Service (JMS), an integral part of J2EE.

Constructing an Integration Workflow Plan

Integration can be defined as two separate processes:

• Inbound integration

• Outbound integration

Inbound integration refers to external systems initiating data requests to a system. Outbound integration means that your local system initiates requests to external systems. The following list details integration types available for both inbound and outbound messaging:

• Message integration This refers to transmission of data between disparate systems in a message-based format. Outbound message integration involves requesting data from a remote system in a format such as a SOAP-based XML message. Conversely, inbound integration means your system is the recipient of a request for data via a message and subsequently responds in kind with a message. Both systems are unaware of object types residing on the remote system. This is especially true for applications that communicate over the wire.

• User interface integration This refers to data transmitted between systems existing as a user-interface presentation. Outbound integration involves requesting a web page from a remote system. Typically, the data will be modified before displaying it as though it were part of a local system’s user interface. Inbound integration entails allowing an external system to request user-interface pages residing on a local system for inclusion on a remote system.

• Remote Procedure Call (RPC) integration of objects RPC integration means system integration using distributed objects. This procedure involves passing data between systems as method call parameters. Outbound object-level integration suggests that a local system invokes objects on remote systems, whereas inbound object-level integration implies that a remote system calls a local system to retrieve data. The benefit derived from object-level integration is that a local object can call APIs with type safety and easily trap exceptions and errors between systems.

• Data integration This means data transmitted between systems exists in a data/record-oriented format. Furthermore, outbound-level integration implies that a local system requests data in record-oriented format from other systems. Conversely, inbound data-level integration means a remote system requests data from the local system in record-oriented format. Data-level integration lends itself to data mapping from one system to another. JCA belongs to this category.