Jakarta Connectors

An EIS provides the information infrastructure for an enterprise. An EIS offers a set of services to its clients. These services are exposed to clients as local and/or remote interfaces. Examples of an EIS include:

There are two aspects of an EIS:

An architecture for integrating Jakarta EE servers with EISs. There are two parts to this architecture: an EIS vendor-provided resource adapter and an application server that allows this resource adapter to be plugged in. This architecture defines a set of contracts (such as transactions, security, connection management) that a resource adapter has to support to plug in to an application server.

These contracts support bi-directional communication (outbound and inbound) between an application server and an EIS by way of a resource adapter. That is, the application server may use the resource adapter for outbound communication to the EIS, and it may also use the resource adapter for inbound communication from the EIS.

An EIS resource provides EIS-specific functionality to its clients. Examples are:

A resource manager manages a set of shared EIS resources. A client requests access to a resource manager to use its managed resources. A transactional resource manager can participate in transactions that are externally controlled and coordinated by a transaction manager.

In the context of the connector architecture, a client of a resource manager can either be a middle-tier application server or a client-tier application. A resource manager is typically in a different address space or on a different machine from the client that accesses it.

This document refers to an EIS as a resource manager when it is mentioned in the context of transaction management. Examples of resource managers are a database system, a mainframe TP system, and an ERP system.

A managed environment defines an operational environment for a Jakarta EE-based, multi-tier, web-enabled application that accesses EISs. The application consists of one or more application components—Jakarta Enterprise Beans, Jakarta Server Pages, servlets—which are deployed on containers. These containers can be one of the following:

A non-managed environment defines an operational environment for a two-tier application. An application client directly uses a resource adapter to access the EIS, which defines the second tier of a two-tier application.

A connection provides connectivity to a resource manager. It enables an application client to connect to a resource manager, perform transactions, and access services provided by that resource manager. A connection can be either transactional or non-transactional. Examples include a database connection and an SAP R/3 connection. A connection to a resource manager may be used by a client for bi-directional communication, depending on the capabilities of the resource manager.

An application component can be a server-side component, such as an Jakarta Enterprise Bean, Jakarta Server Page, or servlet, that is deployed, managed, and executed on an application server. It can also be a component executed on the web-client tier but made available to the web-client by an application server. Examples of the latter type of application component include a Java applet, and a DHTML page.

A container is a part of an application server that provides deployment and runtime support for application components. It provides a federated view of the services provided by the underlying application server for the application components. For more details on different types of standard containers, refer to the Jakarta Enterprise Beans (see Jakarta™ Enterprise Beans Specification, Version 3.2, Jakarta Server Pages, and servlet specifications.

A standard architecture is needed to integrate various EISs with an application server. Without a standard, EIS vendors and application server vendors may have to use vendor-specific architectures to provide EIS integration.

Jakarta Connectors provides a Java solution to the problem of bi-directional connectivity between the multitude of application servers and EISs. By using the Jakarta Connectors, it is no longer necessary for EIS vendors to customize their product for each application server. An application server vendor who conforms to the Jakarta Connectors also does not need to add custom code whenever it wants to extend its application server to support connectivity to a new EIS.

Jakarta Connectors enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server and provides the underlying infrastructure for the integration between an EIS and the application server.

An application server vendor extends its system only once to support Jakarta Connectors and is then assured of connectivity to multiple EISs. Likewise, an EIS vendor provides one standard resource adapter and it has the capability to plug in to any application server that supports Jakarta Connectors.

The following figure shows that a standard EIS resource adapter can plug into multiple application servers. Similarly, multiple resource adapters for different EISs can plug into an application server. This system-level pluggability is made possible through Jakarta Connectors.

If there are m application servers and n EISs, Jakarta Connectors reduces the scope of the integration problem from an m x n problem to an m + n problem.

Figure System Level Pluggability Between Application Servers and EISs

An enterprise tools vendor provides tools that lead to a simple application programming model for EIS access, thereby reducing the effort required in EIS integration. An EAI vendor provides a framework that supports integration across multiple EISs. Both types of vendors need to integrate across heterogeneous EISs.

Each EIS typically has a client API that is specific to the EIS. Examples of EIS client APIs are RFC for SAP R/3 and ECI for CICS.

An enterprise tools vendor adapts different client APIs for target EISs to a common client API. The adapted API is typically specific to a tools vendor and supports an application programming model common across all EISs. Adapting the API requires significant effort on the part of a tools vendor. In this case, the m x n integration problem applies to tools vendors.

Jakarta Connectors provides a solution for the m x n integration problem for tools and EAI vendors. Jakarta Connectors specifies a standard Common Client Interface (CCI) that supports a common client API across heterogeneous EISs.

All EIS resource adapters that support CCI are capable of being plugged into enterprise tools and EAI frameworks in a standard way. A tools vendor need not do any API adoption; the vendor can focus on providing its added value of simplifying EIS integration.

The CCI drastically reduces the effort and learning requirements for tools vendor by narrowing the scope of an m x n problem to an m + n problem if there are m tools and n EISs.

The resource adapter provider is an expert in the technology related to an EIS and is responsible for providing a resource adapter for an EIS. Since this role is highly EIS specific, an EIS vendor typically provides the resource adapter for its system.

A third-party vendor (who is not an EIS vendor) may also provide an EIS resource adapter and its associated set of application development tools. Such a provider typically specializes in writing resource adapters and related tools for a large number of EISs.

The application server vendor provides an implementation of a Jakarta EE-compliant application server that provides support for component based enterprise applications. A typical application server vendor is an OS vendor, middleware vendor, or database vendor. The role of an application server vendor is typically the same as that of a container provider.

The Jakarta EE platform specification (see Jakarta Platform, Enterprise Edition (Jakarta EE) Specification, version 9) specifies requirements for a Jakarta EE platform provider.

The container provider is responsible for providing a container implementation for a specific type of application component. For example, the container provider may provide a container for Jakarta Enterprise Beans components. Each type of application component—Jakarta Enterprise Bean, Jakarta Servlet, Server Pages—has its own set of responsibilities for its container provider. The respective specifications outline these responsibilities.

A container implementation typically provides the following functionality:

The expertise of the container provider is system-level programming, with its focus on the development of a scalable, secure, and transaction-enabled container.

The container provider is also responsible for providing deployment tools necessary for the deployment of application components and resource adapters. It is also required to provide runtime support for the deployed application components.

The container provider typically provides tools that allow the system administrator to monitor and manage a container and application components during runtime.

In the context of the connector architecture, the application component provider produces an application component that accesses one or more EISs to provide its application functionality.

The application component provider is an application domain expert. In the case of application components targeted towards integration with multiple EISs, various business tasks and entities are implemented based on access to EIS data and functions.

The application component provider typically programs against easy-to-use Java abstractions produced by application development tools. These Java abstractions are based on the Common Client interface (CCI).

The application component provider is not required to be an expert at system level programming. The application component provider does not program transactions, security, concurrency, or distribution, but relies on a container to provide these services transparently.

The application component provider is responsible for specifying structural information for an application component and its external dependencies. This information includes, for example, the name and type of the connection factories, and security information.

The output of an application component provider is a Java™ Archive (JAR) file that contains the application components and any additional Java classes required to connect to EISs.

The application component provider relies on tools to simplify application development and EIS integration. Since programming client access to EIS data and functions is a complex application development task, an application development tool reduces the effort and complexity involved in this task.

Enterprise tools serve different roles in the application development process, as follows:

A number of these tools may be integrated together to form an end-to-end application development environment.

In addition, various tools and middleware vendors offer EAI frameworks that simplify integration across heterogeneous EISs.

The application assembler combines various application components into a larger set of deployable units. The input of the application assembler is one or more JAR files produced by an application component provider and the output is one or more JAR files with a deployment descriptor. A deployment descriptor may not be provided by the application assembler if metadata annotations (see Metadata Annotations) are used to describe deployment information.

The application assembler is typically a domain expert who assembles application components to produce an enterprise application. To achieve this goal, the application assembler takes application components, possibly from multiple application component providers, and assembles these components.

The deployer takes one or more deployable units of application components, produced by the application assembler or component provider, and deploys the application components in a target operational environment. An operational environment is comprised of an application server and multiple connected EISs.

The deployer is responsible for resolving all external dependencies declared by the application component provider. For example, the deployer ensures that all connection factories used by the application components are present in an operational environment. To perform its role, the deployer typically uses the application server-provided deployment tools.

The deployer is also responsible for the deployment of resource adapters. Since an operational environment may include multiple EISs, the role of the deployer is more intensive and complex than that in a non-EIS scenario. The deployer has to understand security, transaction, and connection management-related aspects of multiple EISs that are configured in an operational environment.

The system administrator is responsible for the configuration and administration of a complete enterprise infrastructure that includes multiple containers and EISs.

In an operational environment that has multiple EISs, the deployer should manage the operational environment by working closely with the system administrators of respective EISs. This enables the deployer to resolve deployment issues while deploying application components and resource adapters in a target operational environment.

This chapter introduced the roles involved in the connector architecture. The later chapters specify responsibilities for each role in more detail.