| [ Team LiB ] |
|
Working with Java Connector Architecture ComponentsThe Java Connector Architecture is comprised of a number of components. Let's take a look at each of them here. Resource AdaptersThe central component of the Java Connector Architecture is the resource adapter or driver. It serves as the main point of contact between a WebLogic application server the EIS systems and client applications. It plays a pivotal role in providing the system-level software driver used by WebLogic to access an EIS. The driver itself lives within the address space of the WebLogic application server. The system-level contracts, connection management contract, transaction management contract, and security management contract are all implemented by the resource adapter. The application contract is fulfilled by the Common Client Interface between the application component and the resource adapter. There is also a system contract, fulfilled by the system-level programming interface, between the resource adapter and the application server. This includes the management of connections, security, and transactions. A uniform resource adapter is a huge benefit for EIS vendors because they now need only to write to a single API that supports one standard resource adapter. The adapter can then be plugged into any J2EE-compliant application server. Vendors no longer need to customize their product to be supported by different J2EE servers. The benefit for J2EE application vendors is that only one method of communication is required for all EISs. The complexity of the integration problem is thus exponentially simplified. The application API known as the System-level Programming Interface (SPI) includes support for connection management, transaction management, and security. The benefit for application programs is that they can use the same resource adapter. This part of the J2EE Connector Architecture is known as the Common Client Interface. You might have one or more EISs that you want to use as the back end for your application. CCI enables you to seamlessly combine as many as you like into a single application that uses JSPs, servlets, and EJBs to communicate with them. A third part of the Connector Architecture is a standard deployment and packaging procedure for resource adapters. System-Level ContractsFor an EIS resource adapter to conform with the Java Connector Architecture standard, it must adhere to the rules defined in the specification. Rules regarding connectivity between the application server and an EIS are set forth in the form of system-level contracts. The system-level contracts are
The contracts define methods and procedures of communication between an application server and an EIS. Each contract commits the application server vendor and the EIS vendor providing the resource adapter to abide by the guidelines set forth in the connector specification portion of the J2EE Connector Architecture proposal. The guidelines themselves elaborate on the responsibilities that each side must address in order to maintain a uniform interface. Connection ManagementThe connection management contract dictates that the resource adapter must take ownership of creating physical connections to the EIS. The application server is responsible for maintaining a managed pool of connections to the resources that the resource adapter exposes. Client applications establish connections via the pools provided by the application server to available resource adapter instances. An application server registers itself as a listener with the resource adapter to monitor events during the life of a connection. This is required for the application server to dynamically manage the connection pool. Transaction ManagementA transaction management contract exists between a transaction manager and an EIS. It is used by an application server to access the transaction manager. The transaction manager can then be used to manage transactions across multiple resource managers. Security ManagementA security management contract is defined to provide secure access to an EIS and to ensure a secure application environment. It guards against unauthorized access and security breaches that threaten the safety of the EIS as well as the information resources it manages and the clients that access them. In this case as in others, the J2EE Connector Architecture fulfills its security management obligations by drawing on the larger J2EE standard of which it is a part. Authentication and authorization procedures are derived from JAAS (Java Authentication and Authorization Service). JAAS services are called on to enforce legitimate EIS access through JAAS references incorporated directly into the connection management interfaces. Common Client InterfaceThe Common Client Interface (CCI) defines a standard low-level client API for accessing an EIS resource adapter. The API is primarily intended for use by EAI tools to provide a standard method of EIS access that they can conform to. The initial goal of the specification was for use by EIS vendors. It is intended that these vendors build on the base standard to provide a more full-featured interface for application developers. Because it serves as a standard across different EISs, it can be used as a means to span transactions across them. CCI leverages the J2EE JavaBean architecture and Java Collection framework. It uses these components in the creation, management, and execution of connections with an EIS. The CCI itself has no EIS-specific implementations and thus can be used unchanged across any EIS that conforms to the J2EE Connector Architecture standard. The CCI calls for a remote function call interface method of function execution to be used with an EIS. Its primary concerns are in dealing with the calling of remote EIS functions and interpreting their results. Data types bear the most glaring dissimilarity across EIS systems and account for the lion's share of development time during integration efforts. The CCI makes no EIS-specific distinctions on data types and marshals data types in a neutral fashion across disparate EISs. However, it can tie into EIS repositories containing metadata on local EIS data types and pass that information on to higher-level APIs to interpolate. In addition, the Java Connector Architecture also defines a standard SPI (service provider interface) that permits access to a transactional resource manager from the transaction, security, and connection management facilities of the application server. BEA-Supplied J2EE-CA Adapter Client ExampleWebLogic 8.1 ships with a Java Connector Architecture example that's installed at bea\weblogic81\samples\server\examples\src\examples\jconnector\simple. Let's take a look at the key piece of Java code contained in this example, which is used to access the resource adapter:
private Connection getConnection() throws SQLException
{
InitialContext initCtx = null;
try {
initCtx = new InitialContext();
DataSource ds = (javax.sql.DataSource)
initCtx.lookup("java:comp/env/eis/BlackBoxNoTx");
return ds.getConnection();
} catch(NamingException ne)
The example uses a resource adapter that is accessed via an EJB using JDBC in conjunction with the Black Box resource adapter from the Sun reference implementation. As you can see, a simple JDBC getConnection method wraps the adapter call that is made available via the JDBC connection pool configuration on the application server. This represents a seamless method of integrating with EIS resources. Commercially Available J2EE-CA AdaptersA number of J2EE-CA adapters are currently available in the marketplace and are being used to great effect. Here's a brief list of some of the key vendors in the industry and the types of connectors they provide. In-depth information on individual solutions can be found at the following individual vendor Web site links:
|
| [ Team LiB ] |
|