J2EE contains a plethora of API definitions. From the Servlet API to the EJB API, from JMX to JMS. One of the APIs that I have had very little exposure to is the JCA or J2EE Connector Architecture. I have seen it mentioned, not too frequently. Usually in conjunction with EIS (Enterprise Information System) and Integration. Clearly JCA has to do with connecting systems in a standardized way. So I decided to take a closer look – I felt a little left out. And you know, walking into a discussion of J2EE gurus and missing out on the acronyms does not do wonders for your self confidence.
Well, to cut a longish story short: you – and I – will not run into JCA Connectors on a very frequent base. However,
that is not to say we are not relying on them – it’s more like we do not have to know that we do so. Most of the time. Exposing functionality, an integration point, through JCA is typically the job of a vendor of typically large applications, such as ERP systems – think SAP, Oracle, Peoples… uhm Oracle again, etc. – or legacy or at least non standard infrastructures like IBM CICS. By opening up their systems and functionality through JCA, these vendors can integrate with major MOM (Message Oriented Middleware) implementations, ESB (Enterprise Service Bus) infrastructures, EAI (Enterprise Application Integration) products and BPEL (…you know that one don’t you?) Containers. This does not mean to say you will never create a JCA Connector yourself. In fact, later in this article you will find links to articles demonstrating such as task. It is interesting, though not likely to become your everyday’s job.
Consuming services – hey, is this about services all of a sudden? well, yes: an API that provides well defined functionality through a standard protocol is a service in my book – offered through JCA connectors is a slightly different matter. Again, as JCA Connectors are frequently plugged into ESB, EAI and BPEL infrastructures, we will usually not invoke them ourselves, in a direct fashion. Rather we will have the ESB, EAI or BPEL component make the call for us, while we invoke a logical service or partner link.
However, there is absolutely no reason why we cannot invoke JCA Connectors outside these heavy handed architectures. In this article, you will find a few links to resources that describe how you can accomplish that. One relatively obvious way is through Apache WSIF – the Web Service Invocation Framework (see an introduction to WSIF:First Steps with Apache WSIF – Calling out to WSIF-alized SOAP WebServices and Java Classes) WSIF is usually associated with calling Soap Web Services. However, the WSIF framework supports standardized, WSDL based invocations of services implemented in a number of technologies, including EJB, JMS, plain local Java classes and JCA. So if you know how to work with WSIF and you have a WSDL including the JCA binding definition for a JCA Connector based service, you can call directly to JCA services in asimple manner. I intend to write a brief article on this shortly.
Another framework that can help in creating out-of-container JCA Connector calls is – surprise surprise – the Spring Framework. See below for more details.
A useful introduction to JCA for me was: Introduction J2EE Connector Architecture by Anthony Lai, Jyotsna Laxminarayanan and Lars Ewe (03/24/2004), OnJava.com
Creating a JCA Connector
A JCA Connector is created and published to expose proprietary, legacy services in a standardized manner to potential consumers either inside a J2EE Container, an Enterprise Service Bus, a BPEL Container or more or less stand-alone through for example Apacha WSIF or Spring. There is a substantial number JCA Connectors published by for various EIS systems, such as SAP, Oracle EBusiness Suite and IBM CICS.
Sun publishes the BlackBox Resource Adapters for JDBC access to relational databases through JCA, see the chapter on Java Connector Architecture in the J2EE 1.3 tutorial. The tutorial states: “Although the black box adapters use JDBC, resource adapters are not meant to replace JDBC for accessing relational databases.”
During the recent AMIS Query on Oracle WebServices Manager and BPEL (see: AMIS Query on Oracle Enterprise Service Bus, Oracle WebServices Manager, SOA & BPEL. …and not about JBoss), we discussed the new Oracle ESB product (to be released late 2006). One observation regarding JCA: Oracle has developed a number of JCA Adapters, for example for interacting with an FTP server, the file system or a relational database – both Tables and Stored Procedures. These Adapters are used with InterConnect, also with the BPEL Process Manager and the exact same adapter will also be used with the ESB to be. It is good to see an example of such easy reuse of services resulting from the exposure of such services through one of the standard interfacing technologies, JCA. Clearly SOAP WebService would provide the same degree of resuse but a far less simple deployment and (probably) much worse performance.
Also see Develop inbound connectors with JCA 1.5 (Integrate enterprise information systems with J2EE servers) on JavaWorld (June 2005) that describes how to develop a JCA Resource Adapter for a dummy (or rather any) Java class. The theory is discussed at length in Building a Resource Adapter, Chapter 10 from Connector Architecture and Enterprise Application,
Invoking JCA Connectors
Typically, although not necessarily, JCA Connectors are plugged into a J2EE Container and invoked within the container environment, for example by EJBs or MDBs. Since JCA 1.5, the Connector is not only a passive, callable interface – it can also initiate communications with interested parties: Message Listeners. JCA 1.5 provides an enhanced communication model, where the EIS can initiate and control inbound communications, including security context and transaction propagation.
Alternatively and increasingly important, JCA connectors are plugged into Enterprise Service Bus architectures, adding new Service End Points to the ESB infrastructure. Most ESB implementations have native support (Service Containers) for integrating (with) JCA Resource Adapters. Examples include ServiceMix, Mule, Tibco and others.
BPEL Containers, such as Oracle BPEL PM, have built-in support for invocation of PartnerLinks based on JCA Connectors. This means that a JCA Resource Adapter can be imported in the BPEL Process as Partner Link and subsequently its operations can be invoked, just like normal (SOAP based) WebServices can be invoked. The Oracle BPEL Process Manager also provides JCA Resource Adapters for its FTP, File and Database Services. That is: the Java classes that Oracle developed to provide these services have been exposed through a JCA Resource Adapter – that we should be able to plug into other JCA aware infrastructures, such as WSIF or an ESB.
The article Develop inbound connectors with JCA 1.5 (Integrate enterprise information systems with J2EE servers) on JavaWorld (June 2005) not only describes how to develop a JCA Resource Adapter – that we can plug into a J2EE Container – for a fictive service to integrate with. The Resource Adapter is used to publish a Service that initiates inbound communication (inbound from the Service Consumer’s perspective). This article also explains how to set up a MDB (Message Driven Bean) to consume the messages sent from the Resource Adapter – and originally from the EIS that is exposed through the RA.
The Apache WSIF project (WebService Invocation Framework) allows us to call semi-WebServices from our Java application. These services are described through a WSDL but not asssociated with a SOAP binding. WSIF supports WSDL descriptions for services offered by Java classes, EJB, JCA, HTTP GET and POST, and sockets. This suggests – I have not yet tried it out – that by writing a simple piece of Java code that invokes a logically defined service, we can actually be calling a JCA Connector. The document WSDL J2C Extension on the Apache WSIF Project Page describes the JCA basics as well as the way to specify a JCA Service in an extended WSDL format. The article First Steps with Apache WSIF show how to get started with the WSIF library. It can serve as a first step to also get started with calling a JCA Connector through WSIF – out of the container.
The Spring Framework, since release 1.2, provides support for out-of-container access to JCA connectors, or more specifically: CCI (common client interface) for a JAC Connector: “The aim of the Spring CCI support is to provide classes to access a CCI connector in typical Spring style, leveraging’s Spring general resource and transaction management facilities.” See for more details the Spring Framework documentation. The documentation includes an example of how to call upon the Sun BlackBox Resource Adapter (see above) to perform database operations.
Resources
How-To Configure and Use OC4J 10g (10.1.3) JCA 1.5 Resource Adapters
Lucas, your impressions and descriptions over JCA are very interesting.
In the last days i have configurated Sun’s JCA, to use it within ServiceMix.
The JCA was used for inbound & outbound communications between ESB(ServiceMix) and Sun’s Application-Server (Business-Intelligence).
With ServiceMix the JCA was used outside of the J2EE-Container, using Jencks-Container, Spring and POJO’s.
This was my first configuration of JCA outside of a J2EE-Container and maybe a little bit stony – but the results and demonstrated potentialities was very impressiv for me.
cu
Lucas, I understand. My point was that once you start adding transaction and resource management to the bbasic Spring IoC (as the statement in your article seemed to imply), you’ve brought in a large part of the “complexity” as you put it, of what a JavaEE container does.
I’d agree that basic Spring IoC is “lightweight” and is great for what it does. Where I start to scratch my head is when people throw in the “transaction and resource management” aspects of Spring and still call it lightweight…when somehow a JavaEE container that’s doing the same jobs (and requiring similar configuration) is called “heavyweight.”
Peace
Randy, You are right of course in your assessment that Spring is a Container. An IoC (inversion of Control) Container. However, Spring is not itself a formal container such as a J2EE container. When I say out of container, I mean out of the J2EE Container with its complexity, adminisrtation overhead and frequently license fees. Leveraging the Spring IoC Container is pretty easy: add a jar to the CLASSPATH and instantiate (certain) objects through the Spring Container (aka BeanFactory).
To leverage JCA from a standalone Java Application, having to use a fullblown J2EE container is extreme overkill, while bringing in Spring is quite lightweight. As of course would be using Apache WSIF.
best regards,
Lucas
“The Spring Framework, since release 1.2, provides support for out-of-container access to JCA conectors…”
“The aim of the Spring CCI support…leverating Spring’s general resource and transaction management facilities.”
Hmm, isn’t Spring then just another type of “container”? What exactly about accessing a JCA connector from within Spring causes it to be “out of container”?
The Server Side: I just stumbled across a reference to this article on The Server Side. It’s nice to be referenced in this way. See: http://www.theserverside.com/news/thread.tss?thread_id=39376