Java EE Connector Architecture
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 interface (SPI), which has to implement a connector provider, and the Common Client Interface ( CCI) using an application to interact with the connector. In addition, the JCA contains an API for local transaction demarcation.
Previously, the standard was called J2EE Connector Architecture. Since version 1.6 of the specification was from J2EE Java EE.
- 5.1 Configuration of the resource adapter
- 5.2 Dial-up & security
- 5.3 transactions
- 5.4 events
Enterprise Application Integration ( EAI)
The Enterprise Application Integration ( EAI) is an approach for the integration of applications and data sources. This is to facilitate the exchange of data and the connection of business processes.
Before this approach was often trying to solve the problem of integrating their own software solutions and adjustments.
In the applications, it was, however, often to specific point solutions on different platforms and with different communication protocols. Therefore, an integration of the products was achieved only with great effort. EAI now defined a standard that will make communications between applications and data sources available to Native ways. This allows individual parts of the integration are more easily replaceable.
However, the technical differences between the applications and data sources seem to be a problem which must be taken into account for the integration. For Enterprise Information Systems (EIS ), the following distinguishing features are taken into account:
EAI and the Java EE Platform
Due to the large number of different systems, the solution of the EIS integration problem is very complex. Order from an application to access information of an EIS, an application-specific connection has been 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 prepared for each application server. When m and n application servers EIS systems, this means an expense of " m by n ". ( see Figure 1)
Through the connector architecture of this effort is to be reduced. EIS developers do not have to customize each application server their systems. Instead, it is enough if they develop for their EIS an appropriate resource adapter, which can then be integrated into any application server if it supports the connector architecture.
Therefore ensures that the application server can include the resource adapter, the developer need only integrate once the connector architecture. Thus, the effort of integration issues reduced to "m n". ( see Figure 2)
Architecture Overview
In the managed environment (managed environment), which is explained in more detail later, the main components and their interaction can be explained.
The managed environment defines an environment for a Java EE -based, multi-layered and web-enabled application that accesses an EIS. This involves the application of one or more application components such as Enterprise JavaBeans ( EJBs), or Java Server Pages ( JSPs) that 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 standalone application clients
The communication of the Java EE application components is done through the container component contract, which is the connector between a container and the application server. This is defined in the Java EE specification.
In order to access features of the EIS, the application components use a resource adapter. You can access this via its client API.
The system contracts
The integration of the resource adapter in the application server based on the so-called system contracts. From them the interplay of resource adapter and the application server is controlled. Your implementation is mandatorily required by the connector specification.
An application server and a resource adapter work together to keep all system-level mechanisms to the application components transparent. There are therefore three important system contracts required:
For the implementation of the system 3 defines the connector contracts specification interfaces which must be implemented in large part by the resource adapter.
Non- managed environment
Besides the already mentioned briefly managed environment, the connector specification further describes an environment unmanaged ( non-managed environment). This defines a two-layered application. An application client uses a resource adapter directly to access an EIS. Here, no application server is required.
As for this type of integration usually a simple default connection manager resource adapter used is used features are not supported, such as the use of connection pools usually.
In Figure 4 it can be seen as an application client can access a resource adapter to an EIS. The connection factory interface is accessed when a new connection is required. This connection request is passed to the Connection Manager interface, whose implementation takes over the administration of the compound. The generation of the physical connection will be realized by the interface ManagedConnectionFactory. The physical connection to the EIS is represented by the managed connection interface.
Thus, the application client can access the functions of the EIS, he gets a handle of a Connection instance, which was created by the just mentioned ConnectionFactory interface, which he gets access to the EIS.
Managed environment
The aforementioned managed environment will now be considered in more detail, as this is the focus of the connector architecture. In contrast to the non- managed environment, the application components and the resource adapter via contracts with an application server are connected, which thus engages particularly in the connection, transaction, and security management. In contrast to the unmanaged environment can be stated that the implementation of the ConnectionManager interface is done within the application server. Via the system contracts also the access to the resource adapter is controlled by the application server.
Configuration of the resource adapter
Configuration information for the resource adapter such as the server name or port number can be set via a so-called deployment tool. Such a configured resource adapter is used by the application server for making physical connections to the underlying EIS.
Dial-up & security
To obtain a compound, a call to the getConnection method of the connection factory by the application component takes place. This request will be forwarded to the Connection Manager. A connection manager within the application server processes the request and seeks out a suitable connection. If proper connection exists, a new one is created. The data managed by Security Manager security mechanisms (login, password) must agree to use an existing connection.
The management of the connection pool is at the application server and is not determined by the connector specification.
The application server uses the Managed Connection Factory interface for creating physical links, where it is managed connection instances.
As well as in the non- managed environment receives the application component is a handle to this physical connection. Using the Common Client Interface ( CCI ) is again a Connection instance, on which can be accessed on the ice.
Transactions
For local control ( the EIS ), the application server uses the LocalTransaction interface of the resource adapter. Distributed transactions are controlled by the transaction manager, which uses the XAResource interface of the resource adapter.
The transaction manager manages transactions via its own internal mechanisms, which are not defined by the JCA specification.
In Figure 6, a client calls the EJB component X, which carries out an access to the TP system and EJB Y calls. This again speaks to an ERP system. The application server uses a transaction manager to perform transactional access across multiple EIS resource manager.
Events
The Connection event listener interface informs the application server on different events of the physical connection Managed Connection. Events can for example be closing the connection, the occurrence of errors, or the status of transactions.
Note
The previous version shows basic connections of the interfaces within the connector architecture. In order to implement these interfaces, you of course need more detailed information. Details on the interfaces can be found in the Connector specification or the Java documentation for the Java EE SDK.