JCA有什么好处？

Question

Our application often connects to a different kind of back-ends over web services, MQ, JDBC, proprietary (direct over socket) and other kinds of transport. We already have a number of implementations that let us connect from our application to these back-ends and while all of these implementations implement the common java interface, they do not share anything else.

We have realized that there are signification portions of code that are common for all of these particular connector implementations and we have decided to streamline the development of future connectors through one universal connector. This connector will be capable of formatting messages to a format expected by back-end and sending them using the available transport mechanism. For example, fixed-length message format over MQ or over a socket.

One of the dilemmas we are facing is the most appropriate technology for this kind of connector. So far, our connectors were basic java classes that implement the common java interface. Since we generally host our applications in some Java EE application server, it seems that Java Connector Architecture would be the most appropriate technology for this piece of software. However, implementing JCA compliant connector seems to be relatively complex. What are the palpable benefits of going with the standard – JCA and do benefits justify the additional effort?

Answer 1

Indeed JCA seems the most appropriate technology for you. Already excellent arguments have been made, namely the portability, standardised interface, the connection pooling and transaction support. And don't forget security.

With WebSphere Process server the adapters could be exposed as a SCA service which can have a lot of benefits if that's important for you.

Also some development tools have extensive support for developing and testing JCA connectors.

Another benefit is (experienced) Java EE Administrators and Java EE developers (should) know the standard so administration and development should be easy to streamline.

But in the end you should have to find reasons to implement JCA based on the scope of your project, the future plans you have for your project or maybe within the policy of your company.

Answer 2

Short answer: I see no benefit on selecting JCA over other technologies, I see it as a drawback since you need Java EE container.

Long answer:

I've been skeptic about these Java EE standards for some time now. I don't see a compelling technical reason to use a full featured Java EE server anymore, since there are better open source implementations for every feature offered. I've been bitten several times by implementation incompatibilities when moving to/from "enterprisey solutions".

The idea for JCA is surfacing here right now and I am pushing to try apache camel or spring integration instead. I am all for open source implementations that you can use everywhere. And there is a lot going on. Check this list of components . Granted, maybe is smaller than whats already developed with JCA, but every bit is open sourced and it's all on one location. Also, I believe the documentation is simpler and more complete. The urge for integration calls for a powerful SPI with plenty of open source, real live examples, developed in the same fashion, and that can be found on the same place.

I am hating the negativity, but I don't like full featured application servers. For instance, I would go for tomcat and terracota any day over other "enterprisey" products, just as I would go with camel before JCA, until the need for JCA gets proven. I don't like the idea of the Java Committee to tell how I should develop my own applications because I don't trust them. I believe it is in my best interest when the piece of software can work just as easily on Java SE/RCP as in a Java EE environments or in a pure Servlet container.

Answer 3

I've just developed an inbound resource adapter for a gps device communicating over an proprietary protocol. It wasn't that much hassle, though I've got the impression that developing an outbound one might require more work. The worst thing with the JCA is the lack of documentation. All books and articles seems to have the same dumb example.

The thing I'm most pleased with is the portability. Once you've written the adapter you can plug the rar (resource adapter archive) into any application server to provide deployed applications the ability to communicate with eis supported by your ra. Or you can bundle the rar into the war/ear.

Answer 4

The benefits are primarily for vendors who wish to sell connectors to proprietary back end systems for use with any app server, for customers who want to be able to drop in a connector without worrying about whether it only works on WebLogic not Websphere, etc. Indeed this is the goal of Java EE in general.

Note that JBoss has decided to put several things into JCA, for example JDBC connections go via JCA.

Your future client code will have a standardised interface, some pooling and transaction support etc. but it's important to keep sight of the bigger picture; namely that the benefits are not targeted at you and your one project specifically, but at a software eco-system consisting of many app servers, many back end systems, many connectors and so on.

Answer 5

Sounds like a good use for a JBI container with binding components. Discussion of JCA vs JBI.