Connect the
enterprise with the JCA, Part 1
Tutorial Details:
Connect the enterprise with the JCA, Part 1
Connect the enterprise with the JCA, Part 1
By: By Dirk Reinshagen
A look at the J2EE Connector Architecture
he EAI (enterprise application integration) product category has grown significantly over the last 10 years. EAI eases the integration of disparate enterprise information systems (EIS). Although products such as Tibco and Vitria targeting the EAI market have succeeded, they have yet to achieve widespread adoption. As one of its missions, the new JCA (J2EE Connector Architecture) strives to bring EAI into mainstream use.
Read the whole series on the JCA:
Part 1. A look at the J2EE Connector Architecture (November 2001)
Part 2. Build your own J2EE Connector Architecture adapter (February 2002)
The emerging JCA standard provides a mechanism to store and retrieve enterprise data in J2EE (Java 2 Platform, Enterprise Edition). The latest versions of many application servers, including BEA's WebLogic and IBM's WebSphere, support JCA adapters for enterprise connectivity. Using JCA to access an EIS is akin to using JDBC (Java Database Connectivity) to access a database.
Before JCA, each EAI vendor created a proprietary resource adapter interface for its own EAI product, requiring a resource adapter to be developed for each EAI vendor and EIS combination (for instance you'd need a SAP resource adapter for Vitria and a SAP resource adapter for Tibco). To solve that problem, as one of its main thrusts, JCA attempts to standardize the resource adapter interfaces.
In this article, I first deliver a high-level introduction into the JCA. Then I discuss how JCA fits into an integration strategy. After that I compare JCA to EAI vendors' products. Finally, I discuss the limitations of the current JCA platform, followed by what the future may hold.
How JCA and J2EE compare to EAI products
With that background in mind, let's consider how the current version of the JCA specification -- as well as J2EE in general -- measure up to some of the features found in EAI vendors' products.
Many EAI vendors, Vitria and Tibco for example, have either announced JCA support, or are in the process of releasing products that incorporate JCA-based adapters. Because the JCA 1.0 specification was finalized in July 2001, don't expect JCA in its initial release to match feature for feature to an EAI vendor's product, nor is that the aim. (Many features of the J2EE platform also compare to features in many EAI products.)
In light of this, and before we can discuss how JCA fits into the EAI picture, it's important to first understand some basic EAI features:
Resource adapters
Data mapping
Messaging brokers
Workflow
Let's look at each.
Resource adapters
Most EAI vendors include proprietary adapters built to work with their products. Most proprietary adapters allow for synchronous and asynchronous communication to an EIS. JCA adapters closely resemble those adapters, except JCA adapters include only a synchronous communication channel. Resource adapters represent the EAI feature JCA most directly matches, although most EAI vendors' adapters offer a larger feature set (for instance asynchronous capability) than JCA adapters.
Data mapping
With the next EAI feature -- data mapping -- data acquired in one format (for instance in the EIS's native format) by the resource adapter must be transformed into the format required for the business object. Mapping data from one system to another often proves the most time consuming aspect of system integration because you must map each business object in both systems. In response, most EAI vendors provide visual tools to enable a developer to set up such mapping.
While JCA does not offer an equivalent data-mapping facility, EJB's (Enterprise Java Beans) Container Managed Persistence (CMP) facility provides a similar functionality. However, currently not all EJB containers can use EJB CMP with JCA (using JCA as a data resource in place of JDBC). Presumably this will change as JCA becomes more widely adopted.
Message broker
Messaging brokers, another feature common to many EAI products, usually enable both point-to-point and publish/subscribe messaging. EAI products often employ messaging as the connectivity layer to tie together disparate systems.
Currently JCA does not address connectivity to an EIS in a message-oriented manner. It is possible, however, to implement some of a message broker's feature set in an EAI product by using JMS (Java Messaging Service), which is part of J2EE.
Workflow
Workflow is the management of business processes. Think of workflow as a coordinator. In and of itself, workflow lacks the capability to do anything, but rather relies on business objects, messages, and other external entities to perform functionality (for example creating a user object in a database). Workflow coordinates the use of business objects, messages, and so on to perform business processes.
JCA does not address workflow. However, look for something in the J2EE arena to address workflow, as it serves as an important component when developing a complex system.
Having discussed how JCA (and J2EE) compare with EAI tools, it's now important to look at how JCA fits into an overall integration strategy.
JCA and a general integration strategy
These days, many systems must integrate with other systems. But, what does that mean? In this section, I describe various integration types and where JCA fits into them.
Integration falls into two main buckets:
Inbound integration: outside systems initiate data requests to your system
Outbound integration: your system initiates data requests to other systems
All of the following integration types can be applied in both an inbound and an outbound manner.
User interface integration
User interface (UI) integration represents the most coarse-grain type of integration. UI-level integration implies that the data passed between systems will exist in the form of a UI representation. An outbound integration at the UI level entails requesting the UI (most likely a Webpage) from a remote system, then possibly manipulating it before displaying it as if it were part of your system's UI. An inbound integration at the UI level entails allowing an outside system to request UI pages on your system for inclusion on a remote system.
Prefer UI integration over other options when it is unimportant to distinguish the data type being retrieved. UI integration often requires the least effort to implement.
Message integration
Message-level integration, all the rage with the advent of Web services, implies that the data passed between systems will be in the form of a message (a defined, data-driven text format). An outbound message integration involves requesting data from a remote system in a message form (most likely a SOAP (Simple Object Access Protocol) message). With an inbound integration, your system receives a request for data via a message and responds with a message.
Message-oriented integration lends itself to loose coupling between systems because the systems remain unaware of the object types that exist on the remote system. That type of loose coupling works well with applications that wish to communicate over the Internet.
Object/RPC integration
Object/RPC (remote procedure call) integration implies integrating systems using distributed objects (that is, using EJB calls to integrate). With object-level integration, data passes between systems as parameters to method calls. In an outbound object-level integration, your system invokes objects on remote systems, while in an inbound object-level integration, a remote system calls objects on your system to retrieve data.
One of an object-level integration's main advantages is that you can call detailed APIs with full type safety and easily propagate the error codes and exceptions between systems.
Data integration
Lastly, data-level integration implies that the data passed between systems will be in a data/record-oriented manner. In an outbound data-level integration, your system requests data in a record-oriented fashion from other systems. With an inbound data-level integration, a remote system requests data from your system in a record-oriented manner.
The advantage of a data level integration: it lends itself to data mapping from one system onto the business objects in another system. JCA falls into the data-level integration category and therefore has the strengths and weaknesses of this integration type.
Now that we've covered where JCA fits into the overall integration puzzle, we are ready to discuss the JCA's structure.
JCA's structure
Let's begin with a JCA overview. Its main components include the resource adapter, system contracts, and the Common Client Interface (CCI), which together give JCA the power to access data in enterprise systems.
Resource adapter
In order to use JCA in a J2EE container, you first must have a JCA resource adapter, which resembles a JDBC driver. A JCA adapter is specific to an EIS (for example SAP or PeopleSoft) and is contained in a Resource Adapter Archive (RAR) file composed of the jar files and native libraries necessary to deploy the resource adapter on a J2EE container.
A JCA adapter interacts with a J2EE server with system contracts. They enable the J2EE server to propagate the context in which a JCA adapter is being called. You'll find three types of system contracts:
Connection management
Transaction management
Security
Connection management contracts
The connection management contract describes the understanding a J2EE container has with the adapter regarding establishing, pooling, and tearing down connections. The connection management contract also allows listeners created on a connection to respond to events (for instance if the connection becomes lost or experiences an error). Also note that the underlying protocol an adapter uses to connect to an EIS is outside the scope of the JCA specification.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Connect the
enterprise with the JCA, Part 1
View Tutorial: Connect the
enterprise with the JCA, Part 1
Related
Tutorials:
 JavaWorld - Get started with server-side Java - March 1997
JavaWorld - Get started with server-side Java - March 1997
|
The state of Java middleware, Part II: Enterprise JavaBeans - JavaWorld - April
1999
The state of Java middleware, Part II: Enterprise JavaBeans - JavaWorld - April
1999
|
JNDI overview,
Part 3: Advanced JNDI - JavaWorld March
2000
JNDI overview,
Part 3: Advanced JNDI - JavaWorld March
2000
|
J2EE clustering,
Part 1 - JavaWorld February 2001
J2EE clustering,
Part 1 - JavaWorld February 2001
|
XML messaging, Part
3
XML messaging, Part
3
|
Web services hits
the Java scene,
Part 1
Web services hits
the Java scene,
Part 1
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
To EJB, or not to
EJB?
To EJB, or not to
EJB?
|
Connect the
enterprise with the JCA, Part 2
Connect the
enterprise with the JCA, Part 2
|
Create your own type 3 JDBC driver, Part 1
Create your own type 3 JDBC driver, Part 1
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Comparison between the two major JDO architectures
Comparison between the two major JDO architectures
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Should you go
with JMS?
Should you go
with JMS?
|
Good
introduction
Good
introduction
|
Finally, getting hands in !
Finally, getting hands in !
|
Using a JMS Provider with MDBs via the J2EE Connector Architecture
Using a JMS Provider with MDBs via the J2EE Connector Architecture
In this article I will provide a brief introduction to MDB and the J2EE Connector Architecture (JCA), examining how MDBs can be deployed with the JCA 1.5 resource adapter to use a JMS pro
|
Developing Your First Enterprise Beans, Part 1
One of the most important features of EJB is that enterprise beans have the ability to work with containers from different vendors. However, that doesn't mean that selecting a server and installing your enterprise beans on that server are trivial processe
|
Oracle answers on Linux
The world's business software giant offers answers to the 10 most frequently asked questions about Linux.
|
What is Persistence Framework?
What is Persistence Framework?
What is Persistence Framework?
A persistence framework moves the program data in its most natural form (in memory objects) to and from a permanent data store the database. The persistence framework manages the
|
|
|
|
