Java EE Connector Architecture

from Wikipedia, the free encyclopedia

The Java EE Connector Architecture ( JCA ) is a software architecture and programming interface (API) for integration of heterogeneous applications in the Java EE platform. The architecture consists of two parts, the Service Provider Interfaces (SPI), which a connector provider must implement, and the Common Client Interface (CCI), which an application uses to interact with the connector. The JCA also contains an API for local transaction demarcation .

The standard used to be called J2EE Connector Architecture. From version 1.6 of the specification, J2EE became Java EE.

Enterprise Application Integration (EAI)

The Enterprise Application Integration (EAI) is an approach for the integration of applications and data sources. This is to simplify the exchange of data and the connection of business processes.

Before this approach, attempts were often made to solve the problem of integration through in-house developments and adjustments.

However, the applications were often special stand-alone solutions on different platforms and with different communication protocols. That is why it was only possible to integrate the products with great effort. EAI is now defining a standard that enables communication between applications and data sources in a uniform way. This makes individual parts of the integration easier to replace.

However, the technical differences between the applications and data sources that have to be taken into account for the integration appear to be problematic. For Enterprise Information Systems (EIS), the following distinguishing features must be taken into account:

Level of technological support
Includes the possibility of carrying out transactions or supporting security mechanisms .
Administrative and technological restrictions
For example, an EIS can give users different access options.
Ability to integrate with other systems
EISs were often tailored to specific system environments, while communication with other products only played a subordinate role.
System details on the lower level
The client APIs of the EISs can differ. In addition to the use of different programming languages, their complexity can vary greatly.

EAI and the Java EE platform

Due to the large number of different EIS systems, the solution to the integration question is very complex. In order to be able to access EIS information from an application, an application-specific connection was previously necessary. The result was a high development effort, which grew with the number of EIS systems and application servers , since a connection to each EIS must be established for each application server. With m application servers and n EIS systems, this means an effort of "m times n". (see fig. 1)

Fig. 1 - "m by n" integration problem

This effort should be reduced by the connector architecture. EIS developers do not have to adapt their systems to every application server. Instead, it is sufficient if you develop a corresponding resource adapter for your EIS, which can then be integrated into every application server if it supports the connector architecture.

So that the application servers can integrate the resource adapters, their developers only have to integrate the connector architecture once. This reduces the complexity of the integration problem to "m + n". (see fig. 2)

Fig. 2 - "m + n" integration problem

architecture

In the managed environment , which will be explained in more detail later, the most important components and their interaction can be explained.

The managed environment defines an environment for a Java EE-based, multi-layer and web-enabled application that accesses an EIS. The application consists of one or more application components such as Enterprise JavaBeans (EJBs) or JavaServer Pages (JSPs), which run in a container . The following containers are possible:

  • Web container for JSPs, servlets and static HTML pages
  • EJB container for EJB components
  • Application client container for independent application clients
Fig. 3 - Overview of JCA

The communication of the Java EE application components takes place via the container component contract, which represents the link between a container and the application server. This is defined in the Java EE specification.

In order to be able to access functions of the EIS, the application components use a resource adapter. This is accessed via its client API.

The system contracts

The integration of the resource adapter in the application server takes place via the so-called system contracts. They regulate the interaction between the resource adapter and the application server. Their implementation is required by the connector specification.

An application server and a resource adapter work together to keep all system-related mechanisms transparent to the application components. Therefore, three important system contracts are required:

Connection management contract
This allows the application server to manage connection pools to the underlying EIS, which leads to better utilization of connections.
Transaction Management Contract
This contract allows an application server to use a transaction manager to manage transactions across multiple resource managers.
Security Management Contract
The security management contract is intended to enable secure access to the EIS. It provides support for a secure application environment that helps minimize security problems and protects information managed by the EIS.

For the implementation of the 3 system contracts, the connector specification defines interfaces, which to a large extent have to be implemented by the resource adapter.

Unmanaged environment

In addition to the managed environment mentioned briefly, the connector specification also describes a non-managed environment . This defines a two-layer application. An application client uses a resource adapter directly to access an EIS. No application server is required for this.

Fig. 4 - Unmanaged environment

Since a simple standard connection manager of the resource adapter used is usually used for this type of integration, features such as the use of connection pools are usually not supported.

Figure 4 shows how an application client can access an EIS via a resource adapter. The interface is addressed when a new connection is required. This connection request is passed on to the interface, which is implemented to manage the connection. The creation of the physical connection is then implemented by the interface. The physical connection to the EIS is represented by the interface. ConnectionFactoryConnectionManagerManagedConnectionFactoryManagedConnection

In order for the application client to be able to access functions of the EIS, it receives a handle of an Connectioninstance that was ConnectionFactorygenerated by the interface just mentioned, via which it can access the EIS.

Managed environment

Fig. 5 - Managed Environment

The already mentioned managed environment should now be considered in more detail, as this forms the focus of the connector architecture. In contrast to the unmanaged environment, the application components and the resource adapter are connected to an application server via contracts, which thus intervenes in particular in connection, transaction and security management. In contrast to the unmanaged environment, you can see that the implementation of the ConnectionManagerinterface takes place within the application server. Access to the resource adapter from the application server is also regulated via the system contracts.

Configuration of the resource adapter

Configuration information of the resource adapter, such as the server name or the port number, can be set using a so-called deployment tool. A resource adapter configured in this way is used by the application server to establish physical connections to the underlying EIS.

Connection establishment and security

In order to establish a connection, the getConnectionmethod is called ConnectionFactoryby the application component. This request will be ConnectionManagerforwarded to. A connection manager within the application server processes the request and looks for a suitable connection. If there is no suitable connection, a new one is created. The security mechanisms (login, password) managed by the security manager must match in order to be able to use an existing connection.

The connection pool is managed by the application server and is not determined by the connector specification.

The application server uses the ManagedConnectionFactoryinterface to create physical connections, which are ManagedConnectioninstances.

As in the unmanaged environment, the application component receives a handle to this physical connection. Using the Common Client Interface (CCI) it is again an Connectioninstance through which the EIS can be accessed.

Transactions

Fig. 6 - XARessource-based transaction

The application server uses the LocalTransactioninterface of the resource adapter for local control (in the EIS) . Distributed transactions are regulated via the transaction manager, which XARessourceuses the interface of the resource adapter.

The transaction manager manages transactions using its own internal mechanisms, which are not specified by the JCA specification.

In Figure 6, a client calls the EJB component X, which accesses the TP system and calls the EJB Y. This in turn addresses an ERP system. The application server uses a transaction manager to carry out transactional access via several EIS resource managers.

Events

The ConnectionEventListenerinterface informs the application server about different events of the physical connection ManagedConnection. Events can be, for example, the closing of the connection, the occurrence of errors or the status of transactions.

annotation

The previous version shows the fundamental relationships between the interfaces within the connector architecture. To be able to implement these interfaces, more detailed information is of course required. Details on the interfaces can be found in the connector specification or the Java documentation of the Java EE SDK.

Web links

Individual evidence

  1. ↑ JSR 322: Java EE Connector Architecture 1.6 (English)