Most companies have a large investment in legacy systems for ERP, transaction processing, and database applications. Everyone's talking about how they can leverage these systems and integrate them into their modern, multitier, e-business application architectures.
There's an old saying about the weather - everyone talks about it but no one ever does anything about it. Fortunately, this is not true for Enterprise Information Systems (EISs). In fact, IBM, Sun, and a number of other companies are doing something about it in the Java 2 Platform, Enterprise Edition (J2EE) with something called the J2EE Connector Architecture (JCA). VisualAge for Java contains the tooling that was, in large part, the inspiration for JCA. J2EE and JCA are not, as of this writing, finalized and thus no application server or development tool can claim support for either. We'll see, however, that VisualAge for Java's Enterprise Access Builder for Transactions, together with some common design patterns, enables us to leverage JCA in our code.
First let's look at some of the challenges of integrating an EIS into our e-business architecture:
What Is JCA?
- Almost all EIS vendors provide APIs for their products. In general these are proprietary interfaces, which may or may not interoperate well with other software, and they tend to be quite complex.
- Every time an application server vendor wants to support a given EIS, the vendor has to build and maintain a separate interface just for that EIS.
- There's no standard process for managing issues of security, transactional integrity, or connection pooling within the applications; the application developers must reinvent these wheels for each EIS.
Just as JDBC defines a standard API for relational database access for Java developers, JCA aims to do likewise for connecting to and accessing EISs. The JCA defines a standard architecture for connecting the J2EE platform to EISs by specifying a set of scalable and secure mechanisms for integrating EISs. The JCA also defines a Common Client Interface (CCI) for EIS access.
The Connector Architecture
The two key concepts of the architecture are resource adapters, usually provided by the EIS vendor, and application servers, which the resource adapters "plug into." The architecture defines contracts for transaction management, security, and connection management. A resource adapter must support these contracts or it won't be allowed to plug into a compliant application server. This architecture allows any number of application servers to support a given EIS and one application server to support many EISs (see Figure 1). The J2EE Connector Architecture stipulates that the EIS will be the resource manager in instances where transactions are an issue. The architecture also allows the application server to support connection management and connection pooling when scalability and performance are an issue (when are they not?).
Common Client Interface
CCI defines a common API so that each application server can supply tooling to support any and all JCA-compliant EISs. Some of its features are:
The CCI consists of classes and interfaces for the abstraction and manipulation of connections, interactions, records, and connection metadata. You can find these classes and interfaces in the following packages:
- Definition of a remote function-call interface that focuses on executing functions on an EIS and retrieving the results
- A simple, powerful, and extensible API
- Consistency with various facilities defined by the J2SE and J2EE platforms
- Independence from any specific EIS
- Connection-related interfaces:
- Interaction-related interfaces:
- Data representation-related interfaces:
- Metadata-related interfaces:
- Additional classes:
What Is CCF?
As the vendor of CICS, MQSeries, Encina, IMS, and Host on-Demand, IBM is a prominent EIS supplier. It worked with Sun on the development of J2EE, along with other vendors such as Inprise, Oracle, BEA, Motorola, and Sybase. While J2EE was still under development, IBM delivered a working solution to its customers. The Common Connector Framework (CCF) and the Enterprise Access Builder for Transactions (EAB) have been part of VisualAge for Java since 1998. (In addition to the IBM EISs mentioned, the EAB also contains connectors and tooling to support SAP R/3 servers.)
If we examine the components of the Common Connector Framework, we'll see that most of the details and nearly all the philosophy have made the transition from CCF to JCA. The Common Connector Framework features all the same constructs as CCI plus a few extra features:
- Connection/communication specifications
- Interaction specifications
- Records and record types
- Mappers to map records to managed business objects
- Command and navigator beans
Command and Navigator Beans
Figure 2 illustrates how the CCF command bean wraps connection, interaction, and record beans to encapsulate one transaction with the EIS. The command provides getters and setters for the input and output records, a possible fašade for other input and output properties, an execute() method to begin the processing, and events for the successful and unsuccessful completion of the transaction. Not shown in Figure 2 but also very important is the ability to commit or roll back the transaction, if applicable.
Navigator beans are simply an extension of the command beans, which can contain other command beans and navigators. These objects allow us to group multiple EIS transactions and entire subgroups of transactions into meaningful units of work that can be committed or rolled back as one.
The command and navigator beans have a simple, well-defined API that's designed to make them easy to work with in a visual builder tool such as VisualAge for Java's Visual Composition Editor. In the next article we'll make good use of this feature as we build a sample transaction program.
In addition to supporting Java record structures, which is part of the CCI, the Enterprise Access Builder for Transactions also supplies several tools to help automate the creation of certain record types. CICS programs written in COBOL generally have a communications area called a COMMAREA or their screen is defined as BMS maps; IMS screens are defined via MFS maps. The Java Record Builder SmartGuide knows how to read and parse COBOL, BMS, and MFS source files to create input and output record types and records from these structures. In addition, the 3270 Importer is an integrated tool that imports a 3270 terminal source and generates a record type and a record. Figure 3 shows all the options available in the Enterprise Access Builder for Transactions.
The EAB and EJBs
The Enterprise Access Builder can be used in the development of session beans and BMP entity beans in two ways:
- The EAB features a session bean SmartGuide, which can be used to create a session bean that encapsulates an EAB command or navigator, and an EAB session bean editor, which can be used to further refine the enterprise bean.
- After creating a BMP entity bean in the VisualAge EJB development environment, the persistence methods of the entity bean - ejbCreate(), ejbFind(), ejbLoad(), ejbStore(), and ejbRemove() - can be implemented either by invoking methods on an EAB-generated session bean, or by directly executing EAB commands and navigators.
The Path from CCF to JCA
The JCA specification will be finalized in J2EE 1.3, which is expected to be released in 2001. As of this moment, however, JCA and CCI are not implemented by any application server or EIS vendor, and the IBM CCF is not yet ported to JCA. So the question becomes: How do we write code that works now but won't need to be thrown away in the immediate future? We can take a clue from one of the structures provided in the EAB: the Command Pattern.
Command Pattern is one of the patterns discussed in the revered book Design Patterns by Gamma, Helm, Johnson, and Vlissides. The EAB command bean is an implementation of this pattern. If we use the EAB's command bean directly, however, we may risk the maintainability of our code in the future should we decide to move to a different implementation of the JCA or if the EAB changes to fit the JCA as the specification becomes final.
The Command Pattern is one of the shortest and easiest to grasp patterns in Design Patterns. Basically, a Command should provide setXXX() methods, execute(), and getXXX() plus the possibility of thrown exceptions. We would do well to define our own Command interface, which may inherit from one of the existing command interfaces or serve as a fašade. That's exactly the course we'll set in the next column.
Next time we'll build a back-end transaction using EAB/CCF and wrap the transaction in a custom command to make it JCA-ready.
- The JCA specification and information on the CCI: http://java.sun.com/j2ee/connector/
- IBM documentation for the Enterprise Access Builder for Transactions: www7.software.ibm.com/vad.nsf/Data/Document3852
- Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns. Addison-Wesley.
Brady Flowers is a
software IT architect with IBM's WebSpeed team specializing in WebSphere, Java, and the rest of IBM's suite of e-business