Java Connector Architecture project a success

A while back I believe I mentioned that I was reading a book on the Java Connector Architecture for work. I finished reading it over the holidays and got started on it before returning to work in the new year. Last week I wrote the rest of it and am adding the final touches now. It works really well.

I'd like to describe a few approaches I tried before arriving at the decision to use JCA. First, the requirements. I had to write a piece of software that uses sockets and a proprietary protocol to communicate with one of our in-house EIS systems. The EIS system will allow only one inbound connection, and all requests from multiple clients must share the connection (no transaction support). The communication libraries work asynchronously, but users of the library want to communicate synchronously.

Several libraries were written. The first was a wrapper around nio sockets to make working with the socket easier. You could create an instance (which owns a separate thread to monitor the nio selector), set the hostname/port and tell it to connect. You get events when it connects, connection is closed, data arrives, and a few others. The second library is similar to an XML parser, but is for our own proprietary protocol. The third library understands the idea of requests/responses, connections, and our parser. You can send requests using it and when the response arrives it matches it with the original request, then calls back to the sender. There's a lot more to it than that, but that's all I need to describe for this.

Next I needed to have it establish a connection to the EIS when the application server starts so that it's available to EJB's and web apps. My first implementation was a bit odd. I was using JBoss and found out that they have proprietary JMX interfaces I can use that feel a bit like the Windows NT service controller. You get start() and stop() callbacks, as well as the functionality of JMX. I wrote the first implementation using this, so it started as service inside JBoss when JBoss was started. The problem with this is that it is JBoss specific, and that is not what JMX was meant for. JMX is similar to SNMP and is made for monitoring and managing java apps (like the application server itself) with tools like IBM Tivoli. However it worked, and worked well.

The next idea was to write a stand alone java application and have it start up as a real Windows service using the JavaService wrapper utility. This program would have several threads. One thread would monitor config files in a folder for new/modified/deleted files. Each file represented a connection to an EIS. As it detected changes, it would manage a thread for each connection. An other thread operated a JMS consumer. It would wait for requests, broker them to the appropriate connection thread, then pass the response back through a separate JMS Queue. I wrote this in a week or so but never ended up using it. I didn't use it because I found out that I had just re-invented the wheel. This is very similar to what the Java Connector Architecture does.

I read a book on JCA, then re-wrote that program as a JCA resource adapter (RA). It is so beautiful. I deploy my RA to the application server (single .rar file). Next using the web based admin tool for the application server I can create a separate connection pool for each EIS I want to connect to. The application server manages the configuration, connection pooling, all the lifecycle events, and since JCA resource adapters don't live inside the EJB container they are free to manage threads. I was able to use wait(x) and notify() in a few key places to enable synchronous execution of a request for the user of the RA, while everything is asynchronous in the lower layers. This really simplified my source and the design of the system. It is also portable to any application server, even Tomcat. After writing the resource adapter I wrote a web service with a separate method for each type of request. This allows any application in any language to communicate with the EIS using nice objects rather than having to write their own socket code and message builder/parser.