Whether you’re an IT manager or a J2EE architect, if you’re interested in EIS connectivity you’ll be excited about the promises of JCA. What is JCA? What are its most appealing features? What are its shortcomings? Who are the vendors that support it? Are there any other choices so I can do some comparison shopping? What path should I take from here? This article sheds some light on these questions.

First I provide an overview of JCA and its features, then I discuss the type of support provided by the application servers in the market. The rest of this article focuses on the state of the market for JCA adapters. Finally I offer some guidelines to help you determine if JCA is the right solution for you.

JCA Features
Before JCA became available, connectivity to EIS presented a set of common issues and needs. First, each EIS application had its own programming interface. Talking to a different EIS application required programming against a different set of APIs. A common set of client interfaces was needed to simplify the programming effort. Second, the traffic to a back-end EIS application would likely be heavy. You needed connection pooling to cut down connection-related overhead and enhance performance. Third, the connectivity to an EIS application was often transaction-oriented. You needed built-in transaction support to guarantee data integrity with the least amount of programming effort. Last but not least, security integration across EIS applications and EIS clients was highly desirable.

If you think about these issues, they’re similar to the ones regarding connectivity to very early databases. These problems are now resolved due to widely adopted technologies like JDBC. As a programmer, you don’t need to talk directly to a database but you can through the JDBC API, which is the same across all popular databases. You can use connection pooling to a database but you don’t need to implement it. You can use transaction support and security integration easily since support for these features is built-in. Wouldn’t it be great to have a similar technology for EIS applications as well? If your answer is yes, JCA is the answer:

JCA resolves these issues by providing the following features:

• Connection pooling: An EIS connection is usually expensive and time-consuming to create. Connection pooling enables application servers to create and share connections to EIS applications so that expensive connection resources can be used efficiently. JCA adapters and J2EE application servers implement this service.

• Transaction management: This enables an EIS application to be enlisted in the transaction context provided by an application server so that this server can manage the transaction of the EAI system as one unit. JCA adapters and J2EE application servers also implement this ser-
vice.

• Security: Security interface implementation allows application servers to manage overall security without compromising an EIS-specific security mechanism. Authentication, authorization, and secure association are the areas covered by this interface. This is a built-in service for JCA adapters and J2EE application servers.

• Common Client Interface: JCA also defines a user-level programming interface referred to as the common client interface (CCI). This interface set is optional in JCA 1.0 and allows developers of an EIS client to connect, interact (execute a command), and get a result set from the targeted EIS in a standard way.

JCA Support of Application Servers
JCA receives support from two places: a JCA supporting application server and a JCA supporting adapter to an EIS application. JCA 1.0 is part of the J2EE 1.3 specification and a J2EE 1.3–compliant application server must provide the environment to support the required JCA features such as pooling, transaction, and integrated security. Table 1 provides a list of commonly used application servers and their JCA support status.

BEA’s WebLogic Server is one of the early supporters of JCA. JCA beta support was built into WebLogic 6.0 in the beginning of 2001 when the JCA 1.0 specification was in its final draft. With about one year to mature, the award-winning WebLogic Server is one of the best application servers with JCA support. IBM WebSphere Application Server is another popular and award-winning J2EE app server. Its JCA support became available around mid 2001. JBoss is another one that’s worth a special mention. If you’re under a tight budget, you may want to look into this product. It supports JCA and you can’t beat its price – free!

Adapter Vendors
You also need a JCA-compliant adapter to connect to your back-end EIS application. Many integration vendors have built JCA-compliant adapters. Table 2 provides a compiled list of the vendors and the JCA adapters.

In this table, many vendors have JCA adapters for the same EIS application. However, a JCA adapter from one vendor may support a different set of features from the others even if it’s for the same EIS application. This is caused by two factors. (1) Some specifications such as the CCI in JCA 1.0 is optional; it’s up to an adapter vendor to decide whether they want to include this feature in the current release. (2) Some of the important features for EIS integration are not included in the current JCA specification. Adapter vendors may decide to add additional features to enhance an adapter’s functionality. The missing features will be discussed in more detail later.

Since these missing features from the JCA specification can be important ones, most of the vendors surveyed here took a more practical approach and stayed ahead of the curve. One or more additional features were added to their adapters to provide extra functionality even though their implementations are proprietary.

Insevo has JCA adapters for many EIS applications including SAP, PeopleSoft, JD Edwards, and Siebal. These adapters support an XML-based interface in addition to the JCA-defined CCI. They support both synchronous and asynchronous communications between a client and EIS applications. They also support bidirectional communication instead of JCA-defined single direction communication. These additional features make Insevo’s adapters not only suitable for application integration but also for process integration. These additional features are already being considered as part of the JCA 2.0 specification. So in some sense, Insevo’s adapters are one version ahead of the JCA specification. The additional features are not JCA compliant, but if you really need the features can you get anything better?

RAi connectors by Resource Adapters are another set of JCA adapters that took the same approach. They incorporate some of JCA 2.0’s anticipated features. RAi supports both inbound and outbound connectivity as well as synchronous and asynchronous communication modes. In addition to CCI, RAi connectors support XML-based APIs and XML metadata and provide a logging and monitoring utility, which can be a big plus in real life.

In addition, Attunity and Insevo also provide numerous data source and legacy adapters. These adapters usually need only a single direction and a synchronous type of communication. Some of the data sources and legacy systems don’t support JCA features such as transactions. As a result, not all JCA features are fully supported.

Comparison with Other Kinds of Adapters
Other types of adapters are developed for different requirements. One new and important type is a Web services adapter that’s rapidly gaining popularity as well. Web services is an HTTP/SOAP-based integration interface and an XML-based protocol. And a lot of proprietary adapters were developed prior to the introduction of JCA, so these adapters had a longer time to mature.

Web Services Adapter
Nowadays, an enterprise uses all types of platforms some of which are Java-based. Companies invest a large number of resources to develop their systems and usually are not in a position to abandon them. The question is how to integrate these heterogeneous systems so they all work together without an additional investment. Fortunately two very popular technologies make it possible. One is HTTP protocol and the other is XML. They’re the technologies that every platform uses and are a great fit for heterogeneous system integration. Web services is a specification that is built on these two simple yet critical technologies. While the full discussion of Web services is beyond the scope of this article, here’s a short list of Web services features.

• XML interface: Web services is XML based. It uses the Web Services Description Language (WSDL) to describe the service format of the end-point service provider

• HTTP/HTTPS protocol: The de facto protocol for Web services

• SOAP: The binding protocol between WSDL-based Web services and HTTP/HTTPS communication protocol

Web services doesn’t provide any QoS yet and is a synchronous protocol. It’s a good fit for loosely coupled heterogeneous system integration.

The features provided by Web services and JCA complement each other. It won’t be surprising if these two technologies eventually merge their features. In fact, a few vendors have already moved in that direction. For example, vendors like Attunity and Sirvisetti have already built Web services support into their JCA adapters.

Proprietary Adapter
Prior to the introduction of JCA, integration adapters from independent vendors like webMethods and TIBCO have been available for years. These adapters will likely have proprietary APIs that are sometimes nondetachable from their integration packages. However, these adapters have also been tested for years and have much wider EIS coverage than JCA adapters. In particular, the webMethods Enterprise Adapter and B2B adapters have the most coverage by far. webMethods has more than 60 adapters. These adapters don’t support JCA yet, even though webMethods is rapidly moving to support it. Table 3 provides a list of some of these adapters.

Short Term Solution/Long Term Strategy Pros and Cons

The advantages of JCA are obvious. It provides EIS vendors with a way to expose an EIS interface in an open-industry standard. By using the common callable interface and inheriting the QoS provided by JCA, a programmer can simplify the EIS integration effort without sacrificing performance and system integrity.

The limitations of JCA are less obvious but can be important. Like any new technology the immaturity of the initial implementation is often the most frustrating problem to deal with. One specific issue is that JCA adapters should be portable across application servers. However, at this point, this statement may not be true for your application server. The adapter’s support for an application server is tested and released by the adapter vendor on a case-by-case basis.

In addition, there are a few known limitations, some of which will be addressed in the future version of the JCA standard.

• Asynchronous message delivery: JCA 1.0 tackles a synchronous call to EIS applications. It doesn’t handle asynchronous message delivery to and from EIS applications. If asynchronous delivery is a requirement for your company, you may want to use JCA in combination with the Java Message Service (JMS) or another queuing service. The other choice is to use JCA adapters with proprietary asynchronous communication support built in.

• Long-running transaction: This is the type of transaction that may run for days or even months. It doesn’t achieve data integrity by locking resources but by long-term coordination of resources to guarantee the successful execution of a workflow. Long-term transactions are of increasing importance due to the growing need for B2B integration, and that the time span of a process often can’t be controlled by a single trading partner. JCA 1.0 supports DTC-type short-term transactions but it doesn’t support any long-running transactions. If you’re thinking of using JCA to integrate with your trading partner directly, it may not be the best fit. You’re better off using it inside an enterprise and inserting a workflow engine between you and your trading partners for long-running transactions.

• No XML-based interface: There’s no XML-based interface to provide interoperability with non Java–based heterogeneous systems. The result set returned from the CCI is row- and column-based. It’s similar to the result set from a JDBC call to a database. The data returned from the rows and columns are in their native data format. Additional XML-based interfaces can be a big plus for interoperability and data validation.

• Single direction interface: JCA 1.0 only defines a single direction call from a client to an EIS application. It doesn’t define how an EIS application calls the client back. This makes it difficult to use JCA 1.0 as a specification for process-level integration where bidirection communication is often required.

• No adapter metadata: JCA 1.0 doesn’t have a standard way to query an adapter’s metadata.

Is JCA the Right Solution for You?
To answer this question, you need to consider several factors:

• Architecture: Needless to say, JCA has been widely adopted as an open-industry standard and will flourish in the future. It is architecture neutral, and cheaper and easier to implement than most proprietary solutions. It’s simply a better architecture than its competitors.

• Availability: At this point, JCA adapters are in their early releases for a limited number of EIS applications. If there’s a solution for your application server and EIS application and if it’s robust enough for your application, you may want to give it a try. Otherwise, webMethods’ EIS integration solution has been around for several years and is a safer bet. In addition, JCA adapters from different vendors may have different non-JCA features, such as bidirectional communication, asynchronous message delivery, and an XML-based interface, that can be critical factors in your decision.

• Application arena: As I discussed earlier, JCA is currently performance-optimized for synchronous connectivity and designed to benefit from the QoS provided by the J2EE application server. It’s a great fit for an EAI application, but not for B2B integration.

Whether the JCA is for you should be decided on a case-by-case basis. It’s important to keep in mind what the strength and weakness of JCA adapters and their counterparts are and apply your solution accordingly. Whether you choose to use JCA or not, you can learn something from the spirit of JCA architecture. Isolate the callable interface and QoS so that you always have room to migrate to JCA in the future.

Editor’s Note
The Java Connector Architecture completes the story for building enterprise applications for J2EE. Before J2EE CA was available, J2EE application servers enabled development of all the pieces of the jigsaw puzzle except the piece that connected to the legacy systems the data was extracted from. To integrate with these EIS systems, companies provided custom development for each system.

With J2EE CA, a layer of abstraction is provided by the application server vendors for connecting Java platform components to back-end systems. This also fits into the natural evolution of the J2EE application server market. Because of the popularity of J2EE, EIS vendors had to follow suit and offer resource adapters to connect to J2EE components.

At some point the adapter framework and the corresponding adapters should become a commodity offering from J2EE app server vendors. Visualize a design studio, similar to the one offered by BizTalk, where basic connectivity to ERP systems is available in a graphical environment. Of course, customization will still be required, depending on the needs of specific clients. However, getting a prototype up and running shouldn’t be as difficult as it is today.