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.

Changes

I'm going to write a bit about web services -- which is the only technically noteworthy thing I've been doing since my last entry. But first, I'm going to record the events of the past couple of months. After all, this is supposed to be a chronicle of my experiences on this project.

We've had three departures from our team: one voluntary, one involuntary, and one reluctant. The reluctant departure was that of a valued colleague and a good programmer, who fortunately will still be available to me on a contract basis.

We've more-or-less committed to rejecting the financial and project accounting software that we were initially going to use in favour of a simpler package. The theory is that the simpler package will allow for a faster implementation; the more complex package, we've decided, isn't really required at this point since we've narrowed the scope of our project a bit: we're no longer aiming for a system that can be rolled out globally, but simply one that will handle the North American chunk of our major line of business. In other words, about 3,500 employees instead of 26,000. Right now, we're in the middle of three weeks' worth of meetings whose output will be a "model company" around which the system will be designed. Thankfully, I have no role in said meetings.

My own role in the project is a little vague right now. The main part of my job is application integration: defining the interactions between the various applications (HR, finance, project accounting, and project management) that comprise the overall system, and developing interfaces between them. I'm also consulting on the technical architecture. It's still pretty early in the implementation, so there's little actual work to be done: my team is down to myself plus one. At this point I'm investigating technologies, developing spike solutions, and thinking about business cases for solutions that my gut tells me are the right ones.

Within the next couple of weeks, I'll start requirements-gathering on the interfaces. I think the interfaces we require will be comparable to those we developed for the first (aborted) implementation. Hopefully I'll be able to get about 80% reuse out of the existing documentation.