10

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 business problems.

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327

3 Answers3

10

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.

Martijn Verburg
  • 3,287
  • 21
  • 26
  • Can you explain more on 1) the approach we have to take when writing a jca adapter using socket calls as an example 2) what is the reason for making the socket calls from within the adapter than making a socket call directly from within the code 3) How can a socket call be involved in a transaction? There is no way to propogate the transaction to the call receiver right? Can you explain more on what are the transaction semantics in this scenario? – Aravind Yarram Nov 11 '10 at 18:57
  • 1
    @Pangea - This is a deep topic, but in short: 1) It depends on whether you are writing an inbound connector or an outbound connector (you'll want to read up about that). 2) Having a JCA adapter is good because it separates the connection aspects from your core business logic, the adapter (usually bundled as a RAR) will take care of socket handling, connection pooling, propagation of transactions and much more (have a read on JCA on the Oracle site). 3) See 1), sometimes its possible to propagate the transaction that your transaction manager starts or that their transaction manager starts. – Martijn Verburg Nov 12 '10 at 10:21
  • 1
    I ran out of comment space but to continue 3). Think of how a database connection/transaction works - it's the same principle. The App Server might start the transaction which propagates to the database via the Database connector. Yep, most database connectivity is actually written as a JCA under the hood :-) – Martijn Verburg Nov 12 '10 at 10:23
2

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.

Anuj Kaushal
  • 61
  • 1
  • 6
  • I have a component that talks to a tcp/ip application. It takes objects as input and translate them to fixed byte string, send it to the tcp/ip app, gets the response and then transform the resp to obj graph. The problem I have currently is that whenever this component changes, I have to re-package my application as we the component is bundled along with it. Does it makes sense to deploy this component as a JCA adapter? This way I can just redeploy the adapter and restart my application. No need of re-packaging. Does this work? Initially I thought of OSGi so that I can perform inplace updates. – Aravind Yarram Nov 06 '12 at 16:23
  • But making this legacy component OSGi compliant is extra work and seems like the build systems we have are not osgi aware either so it is more work than what we want. – Aravind Yarram Nov 06 '12 at 16:24
  • I think it will be better to let the adapter focus on the integration point, that is the handshake mechanism and reading/writing bytes from/to a tcp/ip socket and let your application do the rest. Oracle has a socket jca adapter which you might want to check out @ref. http://docs.oracle.com/cd/E21764_01/integration.1111/e10231/adptr_sock.htm#BABGEIBH – Anuj Kaushal Nov 06 '12 at 18:17
  • Also found that this thread has a reference to a sample implementation of JCA sockets http://stackoverflow.com/questions/4385373/jca-sample-implementations?rq=1 which might be useful. – Anuj Kaushal Nov 06 '12 at 18:21
2

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.

Owen Chang
  • 41
  • 3