JCA Concepts

Prior to JCA, Java applications were extremely limited in their ability to interact with EISs. Integration required a large expenditure of resources and often resulted in overly complex and hard-to-maintain solutions. The major advantage of the JCA specification is that it is vendor-neutral and yet comprehensive enough to achieve its targeted objectives.

For application servers and EIS integration tool vendors, this is a major breakthrough. JCA converts the integration problem of "m x n" to "m + n."

For example, if BEA had to provide system services and connectivity from its WebLogic Server to CICS, it had to develop a proprietary software component. If WebLogic Server needed to support another EIS with its application server, say, WebLogic to SAP, another new component was required.

Now consider an EIS vendor's perspective of the integration problem. For example, if IBM needed to provide CICS connectivity to WebLogic Server and WebSphere Server, it would have to create two components.

Thus, the end result is having 2 x 3 = 6 components to connect two EIS systems to two application servers (see Figure 21.2). And this problem grows much worse when you consider the large number of different EIS and application servers on the market.

Figure 21.2. m x n problem.

Here's a better scenario. All the companies involved comply with the JCA specification. Each of the EIS vendors creates one system-level driver that conforms to the JCA specification. Now both WebLogic Server and WebSphere Server will implement the JCA specification for integrating with EIS systems. Hence, applications deployed on the application servers conforming to the JCA specification will be able to interact with different EIS systems using a common and standard interface.

The end effect is 5 separate components (see Figure 21.3):

m + n: 2 EIS + 3 application servers = 5 components

Figure 21.3. m + n solution.

JCA streamlines the development of enterprise applications by adding the new component model to the table. By standardizing how the problem is solved, you can see that JCA eliminates a lot of the work that was being done by application server and EIS vendors. If you consider the number of EIS and application server vendors on the market today, it is easy to see how the number of components could grow increasing complex.

Take a closer look now at the concept of design contracts and how they are used in JCA.

Design Contracts in JCA

Contracts are undertaken between two parties when one of them (the supplier) performs some task for the other (the client). Each party expects some benefits from the contract and accepts some responsibilities in return. Usually what one of the parties sees as a responsibility is a benefit for the other party. The aim of the contract is to spell out these benefits and responsibilities.

This concept is extended to software in situations in which software systems and applications are required to interact in specific and standardized ways. This standardized interaction among software systems is called a design contract.

Design contracts play an important role in enabling disparate software systems and applications to interact with each other in a consistent way, thus ensuring portability of applications. In Java, design contracts between systems and applications are enforced by defining interfaces. Because the systems can communicate with each other only via the interfaces, it is left to the discretion of the vendor to implement the functionality behind the interfaces. For example, a software application interacting with System A via a specific interface can interact with another System B without changing any code as long as both System A and System B support the same interface.

A good example of this is the JDBC interface to connect to different relational databases. You have different vendors implementing the functionality of the JDBC interfaces to connect to different databases, such as Oracle, Sybase, Informix, and so on, but the source code of the application using the JDBC interface to interact with the database systems does not have to change.

You already experienced design contracts when you studied Enterprise JavaBeans (EJBs) during Days 10, 11, 12, and 13. In the EJB framework, the main participants are the container, EJB components providing business services, and client applications utilizing the application component services. Hence, the EJB framework specifies two kinds of design contracts for these participants:

• Client-view contract This contract is used for defining a consistent way of interaction between an EJB client application and an EJB container. In the EJB framework, the container performs the mediation between an EJB client and an EJB component. So the client-view contract specifies the interfaces that are available for the EJB client to interact with an EJB container irrespective of the vendor supplying the container. As a part of this contract, interfaces are defined to obtain a reference to the factory within the container for creating EJB component instances (the home interface), to obtain a reference to the implementation of the business interface published by the EJB component (the remote interface), and to obtain some sundry metadata information about the EJB component. The client-view contract ensures that the EJB client applications can communicate with any EJB container without any changes in the source code.

• Component contract Because the EJB container provides the execution environment for EJB components, the component contract defines the standardized way for EJB components to interact with the container. The entire life cycle of an EJB component until it is removed from memory including component instantiation, component activation, passivation, and so on is managed by the container. Hence, defining a consistent environment for EJB components to execute in containers implemented by dif ferent vendors was the primary aim behind defining this contract. The contract defines interfaces that can enable an EJB component developer to develop either transactional (SessionBean) or persistent (EntityBean) EJB components. The container-component contract ensures portability of EJB components across different vendor implementations of EJB containers.

JCA defines a set of standard mechanisms that enable the integration of EISs with application servers. This standard mechanism is actually a design contract between an application server and an RA for an EIS. Two types of contracts exist in JCA:

• System contracts The system contracts define the interaction between the application server and the resource adapter. The system contracts relate to the core functionalities required during the interaction between the application server and the resource adapter for accessing EIS resources such as connectivity, transactions, and security.

• Application contracts The application contract in JCA defines a common set of interfaces for accessing heterogeneous EIS systems. This is accomplished by the Common Client Interface (CCI) API. Standalone application components and EIS tools utilize the CCI API to interact with the RAs of different EIS systems in a consistent way.

In the coming sections you will study the details of the system contracts and application contracts. First let's take a look at the critical piece in JCA, the resource adapter.