Buzzwords

OK, let's talk about web services. Everybody else is.

Being a Java programmer and Unix user, I'm not all that excited about Microsoft's .NET. MS sent me a beta of Visual Studio 7, which I installed, and I spent a couple of hundred bucks on books about C# and .NET just so I wouldn't be too ignorant. But I'm far more interested in J2EE technologies. Java is a very nice language (for those who might be looking to give it a try, I strongly recommend Bruce Eckel's book Thinking In Java...it's the best book on any programming language that I've every read). Our middleware uses JDBC and JMS extensively, and I've played with JSPs and servlets. So, web services are a logical next step (although so are EJBs).

I've had a chat with the architects of the financial and project accounting package that we'll probably be using, and it seems that they've decided to make their APIs SOAP-compliant. They haven't provided me with any further details, but the nice thing about standards compliancy is that once somebody tells you what standard they'll be complying with, you can get started on adapting your code to match the standard. So, I got my hands on a SOAP tutorial from JavaWorld, downloaded the latest versions of Tomcat and Xerces from the wonderful people at Apache, and within a few hours I had a "Hello, World" SOAP example running.

The next step was to do a proof-of-concept, modifying our existing middleware to talk to an API via SOAP. This was no big deal, but it did reveal a problem. Our non-SOAP middleware adapters are Java programs that access the application's PL/SQL API via JDBC, using Oracle's JPublisher. They also access the message broker via JMS. Both JDBC and JMS let the adapter control the transaction completely. So, this means that the data that we're messaging never gets lost: we don't mark it as sent from the application (by commiting to the database) until we've enqueued it on the message broker. At worst, there can be a duplication if the database goes down after we retrieve the data from it, but before we commit the transaction. That's not too bad. Now, we follow the same algorithm with our SOAP adapters, but this time there's another layer: the adapter is talking to the SOAP router via SOAP, which is not transactional and relatively slow. So now, there's a higher risk of a critical piece (the database, the Java SOAP service that talks to the database, and the SOAP router) failing while the overall transaction is in progress, resulting in a duplicate.