JCA: beware!

It has been quite a while since I post last time... I moved to a new apartment and it took all my time. Also, there was not too many interesting things to share, except for my experience with JCA (Java Connector Architecture):

I was involved in a project with the goal of improving one of the mission critical systems of a North European mobile telecom company. I was a great success, the upgrade went well, without major problems.

This system, had connection to 7 other systems. Each connection was implemented in a custom way. The protocols were CORBA, LDAP, JDBC and custom TCP/IP.

When I attended courses held by SUN (Developing Applications for the J2EE Platform and Architecting and Designing J2EE Applications), on both occasions, I was told that using JCA is the right way to implement connection to external systems, although we didn't write any connector due to the lack of time. The benefits I learned were:

1. Generalizing the custom codes
2. Container support (connection handling, monitoring, restart)
   
3. Industry standard

If you heard of these, and consider using JCA, I'd kindly encourage you to not to, or at least, think twice! Implementing JCA was a real pain for me. Here is why:

1. The specification is too complicated with many (I mean MANY!) interfaces.
2. I couldn't find an useful reference implementation
3. The concept of JCA is analogous with JDBC. This is what the container supports. However this is not what you need in most cases.
4. Class loader hell
5. The container support we could use is minimal
   

The 3rd one is the most important one: JCA is good when you can have many, same connections to the external system. This is the case when the container gives you support by pooling the connections. In our case, none of the connectors were like this. We had 1 connection per each of our external systems and we had to perform every operation on this single connection. Typically, this is the case when JCA gives you no help, just pain and waste of time: we ended up createing a JCA framework with ca. 50 classes, plus a generator to generate the connector implementations.

What did I mean by Class loader hell? Well, the problem is that the JCA resource adapters have their own class loader, so if you want to use classes during communication with the resource adapter, you have to package them outside of the connector and outside of your application too. Our dist EAR consist of 1 War, 7 Rars, 16 Jars build from our source, plus 14 3rd party Jars (and there are many connector specific Jars also inside of the Rars). So this is a big mess, but this was the only way we could cope with classloaders. Another possibility would have been serializing between JCA and the app...

If had the chance to start it again, I would have not used JCA at all. I liked the Java Connector Architecture concept very much, so if you have to create a connection fremework, the specification is a good thing to read to give you a few ideas, but then, you will be able to implement an own framework with much less work and complexity. Complexity is time and time is money.

I'd leave it to SAP, Siebel, and co. to create JCA resource adapters for their overproced products. For all others, think again!