Venue: INETS, 2 Floor Chuang's Enterprise Building, 382 Lockhart Road, Wanchai
Agenda:
Free refreshments were provided thanks to the generous sponsorship of BEA Systems.
Integrating Enterprise Systems with J2EE 1.3
Eddie Chui, BEA Systems
Eddie's presentation focused on the J2EE Connector Architecture. Since we can't usually rewrite existing applications in Java, it is often necessary to integrate with non-Java systems. The JCA attempts to ease the burden of integration by providing a standard mechanism for Java clients to connect to Enterprise Information Systems. Version 1.0 of the JCA was included in the J2EE platform for the first time in J2EE 1.3. Version 1.5 of the JCA is currently in development.
Under the JCA, an Enterprise Information System (for example, an Enterprise Resource Planning System, a database, or a transaction processing system) provides a resource adapter that can be plugged into any application server that supports JCA. A resource adapter consists of a JAR file with the filename extension .rar, which contains the resource adapter classes and other JARs, in addition to a deployment descriptor (named ra.xml) and, in some cases, native libraries required by the adapter. A resource adapter can be used in both managed environments (i.e. in an application server) and nonmanaged environments (such as in a two-tier application). A resource adapter talks to an application server through the service provider interface (SPI).
The JCA specifies three system contracts that a resource adapter must implement, for connection management, transaction management, and security respectively. In the case of connection management, the adapter provides a connection factory that creates connections. In a managed environment, the application server will typically support pooling of connections by providing a connection manager. A resource adapter can implement a connection event listener to be notified of connection-related events such as transaction commits and rollbacks.
The transaction management contracts allow for two types of transactions: local transactions, which are limited in scope to the adapter's particular EIS, and distributed transactions, which are coordinated by an external transaction manager (typically provided by the application server) and may span multiple systems. Distributed transactions make use of the Java Transaction API (JTA), which is a Java mapping of the X/Open transaction model and uses a two-phase commit protocol to coordinate transactions.
There was an interesting discussion about using the JCA with custom mainframe applications such as those used by many banks. Daniel DesRosiers pointed out that, in reality, most of these custom applications don't support distributed transactions in any meaningful way. Eddie suggested that, in these situations, a JCA adapter might bypass the service layer and access the application's data source directly. However, in situations where it is hard to work with the data source directly, a pure-Java solution such as the JCA might not be workable.
The security contracts deal with authentication and authorisation, and support both container-managed and component-managed sign-on.
The Common Client Interface (CCI) provides a standardised interface that clients can use to pull data from the EIS, roughly equivalent to the interfaces provided by JDBC for accessing relational databases. The CCI is optional in JCA 1.0, but compulsory in the forthcoming JCA 1.5.
Eddie pointed out a few limitations of the JCA. The current version does not support asynchronous, message-oriented communication (although this might be addressed in version 2.0.), nor does it support callbacks or address workflow. Finally, there is a lack of visual tools for data mapping.
Comparing the JCA to Web services, Eddie pointed out that legacy systems often cannot be extended to support Web services, whereas a JCA adapter can be designed to communicate with such systems using their existing custom protocols. Also, Web services are still lacking standard models for transactions and security. On the other hand, a Web service will support a wider range of clients than a JCA adapter, which supports only Java clients. Also, Web services are designed to work over the public Internet, so connectivity is extremely cheap. Finally, a hybrid solution is entirely possible; a JCA resource adapter could provide a convenient API to Java clients, while using a Web service at the network level to communicate with the EIS.
You can find out more about the J2EE Connector Architecture from Sun's J2EE(TM) Connector Architecture page.