Use cases for JCA

I read that JCA is for legacy EIS integration. Is this spec geared towards vendors and not the application developer? I am curious to know of use cases where developers wrote JCA adapters to solve their technical or bus开发者_如何学编程iness problems.

I've written JCA connectors for all sorts of end systems (FTP, SFTP, File, financial systems).

This is mainly in the investment banking sector where I need to send trade and/or static data to various systems inside and outside the bank. Anything from RESTFul JSON/XML web services to socket calls to a mainframe can be involved in a business transaction.

So JCA comes in real handy is it provides a uniform programming model and can be managed by Application servers which help you with transactionality, pooling etc.

Want the FTP file containing the very expensive trade to arrive (transactionally guaranteed)? JCA is one technology you can use to tackle that.

<blatant plug> I'll add that I currently work on an open source project called Ikasan which has free JCA connectors </blatant plug> as do several other projects such as Mule and Spring Integration. So it's not often the average developer has to write their own.

The JCA stands for J2EE Connector Architecture, it provides means for connecting components run on a J2EE Application Server with the outward world, many existing heterogeneous systems.

In J2EE, you can write presentation layer code running in web container, and enterprise bean in EJB container, but your application is not in a vacuum, you need access other systems and your application also need to be accessed by other system. JCA just provides a standard API for accessing external systems, or being accessed by external systems.

If you are a EIS system vendors, that is Ok, because you want you system be accessed in a J2EE Server.

If your are a application developer, you may also need JCA, because you may need access other system without out-of-box JCA resource adaptor in your application, just write the resource adaptor for your own.

JCA is a collection of connection, thread, transaction, security and lifecycle contracts. By adhering to these contracts, you can offload most of your connection management, thread management, transaction management, security, packaging, deployment, activation, deactivation etc... to the container (JCA compliant application server). Jca also provides an optional cci(common client interface) that allows applications to access the adapter.

Now whether to write a jca compliant connector or not really depends on your applications's requirements.

People generally write jca adapters to access file systems, jms, database, ldap, email, mainframes, packaged applications and just about any other EIS. It really is the developer's prerogative to figure out if writing one is necessary but it's essentially non-trivial to write one.