J2EE Connector Architecture Promises to Simplify Connection to Back-End Systems

Print-friendly Version

© 2000 Giga Information Group

Proof/Notes

The J2EE Connector Architecture defines standard Java interfaces for simplifying the integration of enterprise applications with J2EE-based Java applications. With these interfaces, Java developers can access existing databases, ERP applications and legacy systems. The connector, also known as a "resource adapter," appears as a component library that the developer can access via Java programming language.

The primary goal of the JCA is to ease the development and maintenance of enterprise-scale Web applications. For this class of application, connecting to one or more external systems is the rule rather than the exception. Currently, corporations must either use Java database connectivity (JDBC) for data-level access, or buy, build or partner to get richer application-level connections. Current adapters, however, are platform-specific and offer varying subsets of application functionality. In addition, each adapter requires the developer to learn a new programming interface. In certain instances, adapters suffer from poor scalability and performance, because they were written quickly, often for a specific project, by a third party working with complex or poorly documented application APIs.

Like other parts of J2EE, the specification was developed following the standard Java Community Process and discussions among members of the JCA expert group. This group includes many of the Enterprise JavaBeans (EJB) heavyweights, such as IBM, BEA, iPlanet and several leading ISVs, such as Oracle, SAP and Sybase. The other members of the expert group represent a mix of interests, such as Fujitsu Limited, InLine Software, Inprise, Motorola, TIBCO and Unisys.

Elements of the J2EE Connector Architecture

The J2EE Connector Architecture defines a set of functionality that application server vendors must provide and which back-end system vendors (e.g., SAP, PeopleSoft, Siebel, Oracle and/or third-party connector developers) can use to plug into J2EE. The architecture does not specify how this capability is implemented -- that is up to the platform provider or the connector developer.

The JCA has two basic components, the Common Client Interface (CCI) and a set of system-specific services. An adapter developer provides an interface to CCI along with its side of the system contracts specified as part of the connector architecture. The application server vendor implements its side of the system contracts as part of its base J2EE platform.

CCI is a programming interface that application developers and client programs can use to connect and access back-end systems. It is a low-level API and similar to JDBC. Unlike JDBC, however, CCI can work with nonrelational systems. CCI manages the flow of data between the application and the back-end system and does not have any visibility into what the container and the application server are doing. Although it is possible for application developers to call the CCI directly, in most cases, an application developer will write to an abstraction layer, provided by the connector provider or enterprise application integration (EAI) framework vendor, to simplify the development process.

On the platform side, JCA defines a set of service contracts that a connector developer can expect will be available to the adapter at application runtime. Like CCI, the specification defines what services need to be present, and again, it is up to the application server vendor to provide the actual implementation. The three services in 1.0 include the following:

Connection Management -- Connection management enables the application server to create and manage connections to back-end systems. One important capability provided is support for connection pooling, since connections to back-end systems are expensive. Connection pooling enables an EJB server to pool connections to back-end systems, so rather than opening connections on an as-needed basis, connections with data and services are established, configured, cached and reused automatically by the application server. This contract enables an application server to offer its own services for transaction and security management.

Transaction Management -- The transaction management contract supports transactional access to underlying resource managers. This service enables the transaction manager provided within the EJB server to manage transactions across multiple back-end systems. Connector developers define what level of transaction support they need -- e.g., none, local (with a single back-end system and its resource manager) or XA, with either single or two-phase commit -- for working across multiple back-end systems and their associated resource managers.

Security -- This service enables the developer to define security between the EJB server and the back-end system. The specific security mechanism that is used is dependent on the security mechanism provided by the back-end system. For example, if a system requires Kerberos, then the connection developer will include it. Under the contract, the connector provider must also support user authentication, user authorization and any specific security contracts required by the back-end system.

What's Missing From JCA?

JCA is a promising initiative, but like most release 1.0 initiatives, it has its shortcomings. Many of the shortcomings of 1.0 are known by the expert group and will be added incrementally in an effort to meet time constraints and also leverage new functionality planned for the base platform.

Key missing elements from JCA include the following:

• Support for bidirectional, asynchronous adapters: The JCA 1.0 event model does not support asynchronous communications. It only supports the synchronous request/reply model. This means a resource adapter can call a remote system and wait for response, but the remote system can't initiate a call back to an adapter at a later point. Although this is common in the application server world, it is not well suited for more complex integration scenarios. For example, it is useful in a business-to-consumer (B2C) scenario where the application needs to check availability on a certain item in inventory before processing the order. It is limiting in a high-volume EAI and business-to-business (B2B) scenario involving many disparate systems and where an immediate response from an external system is not critical, or where it is difficult to ensure an external system is up and running. These situations tend to benefit from the flexibility offered by more loosely coupled asynchronous connections.
  
  
• Extensible Markup Language (XML) support: The current version of the common client interface is designed to work with hierarchical and tabular data. Although CCI can be used to support XML, there is no built-in support for dealing with XML records. For example, it would be useful to be able to transform records retrieved from interactions with the back-end system into XML inside of the resource adapter.
  
  
• Metadata capabilities: JCA does not provide any built-in support for working with application metadata. Developers, however, can use whatever metadata API and repository they want. The JCA team is reportedly keeping an eye on what happens with Java Metadata Interface (JMI), so that when it is available, JCA adapters will be able to leverage it.

Giga Analysis

JCA 1.0 promises to simplify the process of connecting to back-end systems. The hope is that by providing this plug-in architecture, it will be easier for application developers to find the adapters; it will be easier for developers to use them, since there will be greater consistency across adapters; and it will be easier to reuse them, since they can be deployed on any J2EE-compliant platform. This is yet to be seen, since currently there are no public JCA adapters or platforms although several vendors have beta implementations. Given that 1.3 is not due for release until spring 2001, customers will not likely see JCA support until mid-2001.

Developers will likely see JCA-compliant platforms first, followed by JCA-compliant adapters. Integrating with back-end systems is a key requirement for e-commerce initiatives. Giga expects that most of the leading platform vendors will incorporate their side of JCA as part of their next major release.

Giga believes that finding JCA adapters will not be as easy. Although Sun expects that enterprise information system (EIS) vendors, such as PeopleSoft, SAP, Clarify, etc., will be motivated to build connectors to their applications, Giga believes this will be unlikely, since adapters aren't core to their business. More likely, the first round of adapters will come from companies that specialize in building connectors. This includes driver vendors, such as MERANT, Attunity and Neon Systems, or EAI solution vendors. In the case of EAI, it will likely be those in the expert group, e.g., TIBCO, or those that have shown early commitment to Java and EJB, such as SAGA and Mercator that will be first to market with JCA-compliant adapters.

Although lack of built-in support for asynchronous capabilities will inhibit the adoption of JCA, this is considered a priority feature for the next release. In the interim, developers have several options they can explore. First, the CCI 1.0 interface provides some basic mechanisms for interacting with message queues (e.g., SYNC_SEND, SYNC_RECEIVE and SYNC_SENDRECEIVE). This is not full async support because interaction with queues can only happen in a synchronous fashion. This approach also doesn't work with nonqueued messaging scenarios, such as publish-and-subscribe (pub/sub).

A second option for developers is to use JCA 1.0 adapters in conjunction with message-driven beans. Message-driven beans are a new kind of bean defined in EJB 2.0 that use Java Messaging Service (JMS) to support async scenarios. Unlike session beans and entity beans, a message-driven bean is invoked by a message. When a message arrives in a queue or a message is "published" on a subject, the container instantiates a message bean instance to handle that message. The message will be taken off the queue and given to the bean as input data. In the case of pub/sub, the message is not removed from the published channel until all subscribers have received their instance.

Most platform vendors have not implemented this functionality yet pending final release of the specification. One exception is BEA, which implemented this functionality in the recent release of WebLogic based on an early draft of the EJB 2.0 spec. IBM reportedly plans to include support in v4.5, although this version will likely not be out until late 2001.

Looking ahead, JCA's importance to J2EE overall may go well beyond its currently defined role. Giga believes that Sun is exploring JCA as a general plug-in model for J2EE. For example, JCA could be used to plug in new protocols. JCA could also support the ability to plug in additional platform services, such as alternative JMS implementations.

Alternative View

It is possible that J2EE Connector Architecture will not become the primary mechanism for integrating with back-end systems. Although this is unlikely, given the success of J2EE and the critical nature of integration requirements for e-commerce, its adoption could be delayed under the following situations:

• Corporations do not move to J2EE 1.3 and/or start to abandon the J2EE platform overall.
• Application server vendors delay investing in JCA extensions until there is sufficient commitment by key adapter providers, such as the EAI vendors, to provide JCA-compliant adapters.
• Adapter providers do not invest in making their adapters JCA-compliant.

Failure of J2EE is unlikely, particularly given the success of products such as IBM WebSphere and BEA WebLogic. A more likely scenario would be a J2EE slowdown as companies begin to grapple with its complexities. Corporations that are dealing with short development time frames and that lack Java skills may instead turn to alternative application platforms, such as Windows DNA.

Given the value of the new 1.3 features, particularly for e-commerce applications, it is unlikely that application server vendors will not move to 1.3. Since most e-commerce applications need connections with external systems, Giga believes that platform vendors will see JCA as a priority.

Market acceptance of JCA will largely depend on the availability of JCA-compliant adapters. It is unlikely that current adapter providers will make all of their existing adapters JCA-compliant at once. It will likely happen gradually over time based on customer demand.

Findings & Recommendations

As the world converges around the J2EE platform for both business logic and application integration, Giga believes that if J2EE follows along its current path, JCA will eventually emerge as the dominant means for connecting to back-end systems when an application server is involved. This, however, will take time. Platform providers need to add the necessary pieces outlined above, and adapter providers need to modify existing adapters or build new ones. Assuming Sun meets its slated release of J2EE 1.3 in early 2001, there are unlikely to be significant commercial implementations of the platform and connectors until later in 2001.

For most Giga clients, there is no immediate action that needs to take place with respect to JCA. However, as vendors begin to deliver J2EE 1.3 support, Giga suggests the following recommendations:

• Corporate clients that are standardizing on EJB/J2EE application servers should plan to use J2EE connectors starting in mid-2000.
• Vendor clients that either build e-business solutions that integrate with back-end systems or that build application adapters should explore JCA and what it could offer.
• Corporate clients that plan to use JCA 1.0 connectors should plan to use them only for classic synchronous things like wrapping mainframe transactions or for invoking application APIs where a synchronous approach makes sense, for example, in a B2C shopping application involving limited inventories.
• Companies shouldn't expect to see support for async adapters until late 2001 or early 2002.
• Those that need async integration prior to JCA 2.0 have several options: (1) use existing CCI functionality to interact with message queues, (2) explore use of message-driven beans and JMS, (3) write message-oriented middleware code inside other Java components or (4) use a third-party integration server that integrates with EJB, even if only at a distance. The choice between these alternatives should be made using the same criteria that would always apply to choosing to use an integration solution.

References

Related Giga Research

• Planning Assumption, 2000 Forecast for the EJB Application Server Market, Mike Gilpin and Carl Zetie
• Planning Assumption, JCP 2.0 Is a Way Station, Not the Final Destination, Carl Zetie
• Planning Assumption, Introducing an Internet Application Integration (IAI) Architecture Framework for E-Business, Mike Gilpin
• IdeaByte, Integration Issues Drive Growth in EAI and Application Server Partnerships, Jane Stanhope

Relevant Links and Other Sources

• Sun's J2EE Connector Architecture, http://java.sun.com/j2ee/connector/