JCA Adapter Support in webMethods 6 By Phillip Leary

---

Introduction to webMethods and JCA

One of the compelling features of the webMethods integration product suite is the wide range of adapters available for connections to enterprise resources.

Historically, webMethods has provided two distinct types of adapters: Enterprise Server Adapters, and Integration Server adapters. Enterprise Server adapters were designed to be used in document-centric integrations utilizing the webMethods Broker, and the Integration Server adapters were designed for use in service-centric integrations.

For enterprises implementing both the Broker and the Integration Server, there was often a choice to be made as to which type of adapter to use when connecting to a specific back-end system.

With the release of the new webMethods 6.0 Platform, webMethods has announced support for a new type of adapter -- an adapter based on the J2EE Connector Architecture (JCA) 1.0 specification.

This new adapter type is designed to provide a consistent, standards-based method for connecting to enterprise resources, and will eventually replace the existing Broker and IS adapter types.

---

J2EE Connector Architecture

Most integration vendors -- webMethods included -- use mostly proprietary architectures to establish connectivity between enterprise resources.

The reasons for this are numerous: convenience, speed, architecture necessity, etc. One overarching reason is there has not been a Java specification addressing how to integrate heterogeneous enterprise information systems. Without a standard to follow, each vendor has addressed this issue in their own way.

The J2EE Connector Architecture specification is designed to provide this standard.

JCA, as indicated in the name, is part of the J2EE architecture. The J2EE architecture describes technologies and standards supporting application components, such as client applications, web applications, and Enterprise Java Beans (EJB). These components are hosted on a J2EE server, called an application server, which provides deployment and run-time support for the components.

The JCA specification adds support for connections to non-J2EE resources, and leverages the capabilities of the application server in doing so.

The JCA specification is still evolving, so at this time the specification does not address all of the necessary issues. As a result, much of the current JCA support available from integration software vendors is actually a merging of the JCA standard and additional, vendor-specific features.

Before we jump into JCA support in webMethods, let's take a look at what the current JCA specification provides.

The JCA specification 1.0 consists of three main components:

1. Resource Adapter
2. System Contracts
3. Common Client Interface (CCI)

---

JCA Resource Adapter

The Resource Adapter provides the connectivity between the application server and the enterprise resource.

In the JCA specification, enterprise resources (such as SAP, Siebel, DB2, Oracle, etc.) are called Enterprise Information Systems (EIS). Each JCA Resource Adapter will be specific to an EIS and interact with the EIS via the native libraries and API of the EIS.

The Resource Adapter resides in the memory space of the application server and interacts with application server components via a set of system contracts.

---

JCA System Contracts

System Contracts define the support the application server will provide to Resource Adapters.

Activities common to all Resource Adapters are encapsulated in these contracts. This places the burden of system-level mechanisms on the application server. As a result, developers of Resource Adapters can focus on presentation and business logic and not get mired down in lower-level details.

There are a number of system contracts in the JCA 1.0 specification. Key contracts include Connection Management, Transaction Management, and Security.

Connection Management
The connection management contract defines the responsibility of the application server in establishing and managing connections to the EIS.

The application server creates, pools, and removes connections, as well as propagates connection events (such as the loss of a connection) to components using these connections.

Transaction Management
The transaction management contract requires the application server to support two types of transactions: local and distributed.

Local transactions are those created for a particular EIS. For example, a database adapter may pass a command to the database to start a transaction, execute several table inserts, and then commit or rollback the transaction. This transaction is local the the database resource.

Distributed transactions are transactions created somewhere other than the EIS. For example, a client application component creates a transaction and then utilizes a JCA resource adapter. The transaction originating in the client application component will be passed on to the resource adapter and through to the EIS.

In this way, two-phase commits may be supported.

There is another transaction-specific contract in the JCA, called the transaction inflow contract. This contract allows EIS-created transactions to be propogated to the application server.

Security
The security contract allows the application server to connect to the EIS system.

The application server maintains security credentials, such as a user ID/password or digital certificates, and uses these to establish the connection to the EIS. The security contract allows for either Component Managed Sign-On or Container Managed Sign-On.

In the case of Component Managed sign-on, the security credentials are passed to the EIS each time the Resource Adapter creates a connection to the EIS. Each component requesting a connection to the EIS may pass connection-specific security credentials.

With Container Managed Sign-On, the application server manages the security credentials.

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums