The J2EE Connector Architecture specifies a standard architecture for integrating J2EE applications with enterprise information systems. The J2EE Connector Architecture 1.5 specification provides bi-directional synchronous/asynchronous communication, message provider pluggability, lifecycle management, transaction inflow and thread management.

Download the J2EE Connector Architecture.

 The examples for V1.0 are annoying: repeated what JDBC does and implemented the interfaces that are not JSE1.4 compatiable. I wish they had better examples.

Agreed - it was a little unfortunate that Sun provide RDBMS based examples for connecting technology intended (at least originally) for non-RDBMS integration.

BEA used to have some interesting non-RDBMS examples available for download or "evaluation" from their website, including an FTP adapter. I'm not sure how much effort is required to get these examples running in other servers though.

Its great to see inbound communication supported in the specification, finally we'll be able to invoke MDBs without having to use JMS.

Anyone have any idea what was dropped from the JSR, wasn't it going to be JCA 2.0 - why the change ?

RDBMS example should give you an idea how to manage transactionality in your own adapter. And in my opinion, BEA's FTP adapter is crap (btw it is using proprietory BEA's ADK and buggy ftp library).

The most weak area in the Connector Specification is the contract for metadata definition for the Records created by the adapters.

Basically it is very difficult to connect two adapters from different wendors to each other. You will need to implement proprietory code to transform Record data from one format to another. And if you will do it through XML - it will dramatically drop the performance (especially for the binary formats such as EDI or IDOC or for object model provided by the end system, such as Java API's provided by the most of ERP/CRM vendors).

I think you'll find that the whole CCI part (such as Records, Interactions etc) is optional - so you can use the same "objects model" as your "end system", and just add some classes for the application server to handle connection management.

I've retro-fitted, or wrapped, a few APIs into resource adapters using this technique without any significant degredation in performance.

As for examples, another source is Dirk Reinshagen's article that included example code - which doesn't use any WLS specific libraries (other than having a weblogic-ra.xml file), and can be download from Javaworld at the following URL:

http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-jca2.html

That's what I'm saing. It is not a problem to wrap any API, but at the some point you will have to use very proprietory code to populate or retrieve your data. In my view that Record interface should be mandatory for CCI and metadata management should be more standartized.