J2EE Connector Architectureby Anthony Lai, Jyotsna Laxminarayanan and Lars Ewe
Have you ever found yourself in a position where you had to integrate legacy data, data sources, or functionality with your new application? If so, rest assured that you are in good company. Many development organizations find themselves in the same situation.
This article discusses some of the challenges of legacy system integration, then introduces the J2EE Connector Architecture (J2EE CA) and explains how it can significantly reduce the problems of integrating your legacy system. It also offers a comprehensive example of how to use the current version of J2EE CA, version 1.0, to access a common transaction-processing platform from a Java 2 Enterprise Edition (J2EE) platform application. This article concludes with an overview of the upcoming new release of J2EE CA, version 1.5, and explains some of the additional features and benefits introduced in this new version. This article assumes that you have a working knowledge of Java and J2EE.
If you've ever had to integrate legacy data, data sources, or functionality with a new application, you've no doubt faced a number of challenges: for instance, figuring out how to connect to legacy systems, manage connections, and convert different data types between the systems. Most likely, you either implemented your own mechanisms to address these issues -- that is, if you had the time and knowledge -- or you licensed proprietary third-party technology to do so. And chances are, the final solutions cost a significant amount of time and money -- and most of it was spent solving the underlying infrastructure challenges, not the real business problem at hand.
Without an easy standards-based solution, you didn't have much of a choice.
Fortunately, J2EE Connector Architecture (J2EE CA) has changed this. J2EE CA is a standards-based mechanism of accessing legacy systems from Java / J2EE applications that significantly reduces the challenges of legacy system integration.
J2EE CA is best explained with a simple analogy. Most developers are familiar with the Java Database Connectivity (JDBC) API, which lets Java programs access relational databases in an easy, standardized way. Before JDBC came along, it was much more difficult for programs to access and interact with databases.
Programs used data source-specific mechanisms and features, as well as different data conversions, so unless you had specialized domain expertise, you were faced with substantial project delays, project quality issues, database implementation lock-in, and other problems.
J2EE CA is to legacy data and application integration as JDBC is to database interaction. It provides a standardized, easy-to-use, legacy system-independent way to communicate with the different backend systems that your project must integrate with. By doing so, it lets you reuse technology as well as domain expertise. J2EE CA is more generic in its approach than JDBC, however, providing connectivity to a broader spectrum of backend systems. JDBC assumes that data will be of a relational nature; J2EE CA does not.
Once JDBC was introduced, did you ever consider not using it, or JDBC-based technologies (such as TopLink), to access different data sources from Java or J2EE applications? Probably not. We're convinced the same will be true for J2EE CA. Once you learn how to use it and you start enjoying its benefits, you won't want to use any other method to integrate applications with legacy systems.
Let's take a look at J2EE CA 1.0, its functionality, and an overview of its high-level architecture.
At the heart of J2EE CA 1.0 are several standardized contracts and interfaces between different parties. The parties are the backend enterprise information system (EIS), the different application components, the application server, and the resource adapter. Let's look at each one:
EIS: This is the backend legacy system that the application components must integrate with.
Application components: These are Java or J2EE application components (for example, Enterprise JavaBeans) that must integrate with the EIS.
Application server: The application server (for instance, Oracle Application Server 10g) provides the runtime environment (container) in which the application components and the resource adapter execute. It also furnishes system-level services such as connection, transaction, and security management.
Resource adapter: This connects application components with the EIS by implementing system-level services specific to the EIS, thereby shielding the application components from the EIS-specific system-level services. It plugs into the application server by using standardized system contracts.
The standardized contracts and interfaces between the different parties are the container-component contracts, the system contracts, and the optional common client interface (CCI). The resource adapter uses EIS-specific contracts to communicate with the EIS. Here's some more information on the different contracts and interfaces.
Container-component contract: J2EE component contracts standardize the interaction between the application components and the application server. For example, in the case of EJBs, the contract is the Enterprise JavaBeans specification and its different guarantees and interfaces between the EJB container and the hosted EJBs running inside the container. Transactional attributes, security attributes, other common J2EE component attributes, interfaces, and services are well integrated with the J2EE CA system contracts (mentioned below). This is because J2EE CA functions as a bridge between the resource adapter and the remainder of the J2EE application server, its services, containers, and any components running in those containers.
System contracts: J2EE CA contracts between the application server and the resource adapter to standardize things such as security management and transaction management.
CCI: This J2EE CA client interface standardizes the interaction API between the application components and the resource adapter. Although CCI is a great feature, it's optional, so not all J2EE CA-compliant resource adapters provide one. Some resource adapter providers offer EIS-specific client interaction interfaces instead.
By defining the above contracts and interfaces J2EE CA helps developers, as well as resource adapter providers.
It offers developers standardized ways to connect to the EIS, managing security credentials and transactional boundaries. For most resource adapters, developers can also use the CCI to interact with the EIS. To revisit the JDBC analogy, CCI offers a standardized interaction interface to the EIS, similar to what's provided to database developers with ANSI SQL.
Resource adapter providers can write adapters that can be deployed and used across different J2EE application servers. They can rely on a set of system contracts that lets them implement adapters that are tightly integrated with application server functionality, such as security and transaction management, without having to implement any application server vendor-specific interfaces.
J2EE CA 1.0 in Action
After all this theory, let's take a look at a real-life example. Let's see how you can leverage J2EE CA 1.0 to connect a simple Enterprise JavaBean to a common transaction-processing platform, in this case BEA Tuxedo.
Our example uses a J2EE application that runs on Oracle Containers for J2EE (OC4J) 9.0.4 -- a J2EE-compliant application server with full support for J2EE Connector Architecture 1.0 -- and interacts with BEA Tuxedo 8.1 transaction server. The example also uses Attunity Connect 4.x, which provides standard integration between resource adapters and enterprise data sources, as well as legacy applications. The solution includes a resource adapter deployed in OC4J, and the Attunity Connect Engine configured on the target system. Attunity Connect can be used to access a wide variety of systems, including CICS, IMS, VSAM, Adabas, Tuxedo, RMS, and Enscribe.
To follow along with this article, please download the example files in oc4j-jca-tux.zip. Figure 1 shows the architecture of the sample application.
Figure 1. Architecture of the stockquote sample application.
Here are the high-level steps necessary to reproduce the example:
- Set up and configure the backend EIS (in this case, Tuxedo).
- Set up and configure the J2EE CA resource adapter and deploy it to the J2EE application server (in this case, Attunity's J2EE CA Tuxedo adapter).
- Implement and deploy the J2EE application that interacts with the EIS by using the J2EE CA resource adapter.
Let's take a closer look at these steps: