The Enterprise Architecture Integration (EAI) provides a common framework for integrating incompatible systems running on different platforms. Many legacy applications and custom databases are still being used and run well that there is no need to re-invent the wheel. The aim of EAI is to reduce the complexity of the IT infrastructure and improve reliability, scalability and flexibility.
This article provide a brief description of a technology that is a key in integrating the databases and legacy systems with J2EE technology. Java 1.4 came with JCA 1.5 (Java Connector Architecture) that provide the standard mechanism to store, retrieve data from EIS (Enterprise Information System). To understand how JCA fits into EAI, refer to Connect the Enterprise with JCA.
Why JCA?
J2EE container is responsible for managing the security, threading, resource pooling and so on. In order to ensure the control over their functions, the container put some restrictions on components it manages such as EJB and servlets.
One of the restrictions is on EJB and IOs in general. An EJB should not manage a file descriptors (Sockets or Files). The communication with EIS is done through Sockets. Sockets are the standard low level communication primitives that appeared in early 1970's for Unix systems. The Sockets are not serializable therefore, EJB cannot passivate them neither the servlet can put them in session. In distributed environment, EJB are distributed at runtime running on separate JVM or machines. More information about EJB restrictions may be found at EJB Restrictions .
But EJB should find a way to communicate with databases and other EIS system. JCA provides the solution where the JCA handles the low level connections with EIS and return a Handle for the connection to the J2EE middle tier components.
Before we start the implementation of a Resource Adapter to provide SSH and Secure FTP functionalities, let's list the main JCA components:
- System contracts
- Client API
- Resource adapter module
System contracts define the connection between the application server and the EIS. The EIS side of the system contract is implemented by a resource adapter
-- a system-level software driver specific to the EIS. The application server and the resource adapter collaborate by means of the system contract to provide secure, robust, scalable access to the EIS.
Three types of system contracts are defined:
The connection management contract enables physical connections to the EIS and provides a mechanism for the application server to pool those connections.
The transaction management contract supports access to an EIS in a transactional context. Transactions can be managed by the application server, providing transactions that incorporate other resources besides the EIS, or they can be internal to the EIS resource manager, in which case no transaction manager is required.
The security contract supports secure access to the EIS. How system contracts are implemented on each side (application server and resource adapter) is not specified by JCA; they can be implemented as each vendor sees fit.
Client API
The second element of JCA is the client API. The API can be specific to the resource adapter or it can be the standard Common Client Interface (CCI) as defined by JCA. The CCI is meant to be used by vendors to provide integration tools and frameworks, making it easier for developers to access enterprise systems. It is recommended (but not mandated) that the resource adapter make use of the CCI.
Resource adapter module
The resource adapter module contains all of the elements necessary to provide EIS connectivity to applications. Specifically, the resource adapter module includes the following components:
- The Java classes and interfaces that implement the resource adapter
- Any utility Java classes required by the resource adapter
- Any EIS-specific platform-dependent native libraries
- The deployment descriptor
Application servers make use of the deployment descriptor supplied with a resource adapter to configure it to a specific operational environment.
Handling of Connections
An application component accesses the resource adapter through ConnectionFactory and Connection interfaces, which are provided by the resource adapter implementer. These interfaces can be CCI interfaces (
javax.resource.cci.ConnectionFactory and javax.resource.cci.Connection) or they can be specific to the resource adapter. The classes that implement these interfaces are also provided with the resource adapter.The connection factory is obtained through the Java Naming and Directory Interface (JNDI) so that the application need have no knowledge of the underlying implementation class. Once the connection factory is retrieved, a connection is obtained from the connection factory through the
getConnection() method. At least one getConnection() method must be provided by the connection factory, though more may be provided. It is important to note that a Connection is an application-level handle to an underlying physical connection to the EIS, represented by a ManagedConnection. Once the application component is finished with the connection, it calls the close() method on the connection. A resource adapter is required to provide a method on the connection to close the connection. This method must delegate the close to the ManagedConnect ion that created the connection handle. Closing a connection handle should not close the physical connection to the EIS.Managing Connections
The getConnection() method in the connection factory does not actually create a connection;
it calls the allocateConnection() method on its associated ConnectionManager.
The ConnectionManager interface is implemented by the application server.
It is associated with a connection factory in an implementation-specific manner when the
connection factory is instantiated. The call to the ConnectionManager allows the application
server to "hook in" to the resource adapter functionality to provide pooling, transaction,
and security services. A ConnectionRequestInfo object may be passed to allocateConnection()
to pass connection request-specific information.
The ConnectionManager, in turn, calls on a ManagedConnection to obtain the connection
handle. The connection handle is passed back through the ConnectionManager to the connection
factory and on to the application component.
Connection Pooling
The resource adapter provides a class that implements the ManagedConnectionFactory interface. The ManagedConnectionFactory class acts as a factory for both connection factory instances and ManagedConnection instances. When the application server needs to create a connection factory, it calls the createConnectionFactory() method, passing in an instance of ConnectionManager; this is the instance that is called when the application component calls getConnection() on the connection factory, as discussed previously.
The application server uses one of two ManagedConnectionFactory methods to create or request managed connections. When the server requires a new instance of ManagedConnection, it calls the createManagedConnection() method. When the server wants to re-use an existing ManagedConnection, it calls the matchManagedConnections() method. To find the right match, the server passes in a set of ManagedConnections that could possibly meet the criteria of the requested connection, along with information about the desired connection type. Internally, the matchManagedConnection() method compares this information with the candidate set to determine if a match can be made. If so, it returns the matching ManagedConnection; if not, it returns null.
So far we have talked about the outbound. JCA also supports the inflow and is implemented using ActivationSpec and Inbound Message Driven Bean.
The following depicts the design of the SSH adapter.
The code can be found at http://txconnect.sf.net
By Sadi Melbouci
References:
Connect the Enterprise with JCA: http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jca.html
No comments:
Post a Comment