Take a Walk on the Wild Side

I recently found myself in the interesting position of being asked by my client to help them write a web service client...in Java. I know basically nothing about Java, but I'm usually pretty good about picking things up quickly, so I dove in. I don't think I have anything particularly technical to add to the body of knowledge, but I thought I'd relate my experience as a complete Java n00b in the web services space.

My initial involvement in the effort happened after the client's attempts to get Axis working failed. This was probably due to the fact that Axis seems to be primarily a server-side technology, and they need to get it working from within an applet running in a browser (they're providing a rich UI for a complicated part of an ASP.NET web application). I imagine we could have gotten Axis to work had we banged on it for long enough, but this part of the project was rapidly becoming the biggest schedule risk. So I went and asked some of my smart Java friends what they recommended as an alternative.

One of them suggested XFire. It seemed like a reasonable alternative, but my client was unable to get it working either, even after a few days of hacking on it. Meetings were called, and more and more senior managers were called in. This is where I took an active hand.

Not knowing anything about Java or Java web service toolkits, I figured that given all the knobs and buttons we were having trouble figuring out, the most predictable route was one that eschewed web service toolkits entirely. So I asked some smart friends again, and got pointed to JAXB, which is Sun's equivalent of XmlSerializer. Once I located xjc.bat, I was able to generate some simple classes and to serialize/deserialze them to/from XML within a few hours.

At that point, I felt a lot better. The code to do low-level HTTP in Java is pretty straightforward, and with the JAXB-generated classes, I knew we'd be able to do what we needed to do. But since I was now slightly ahead of the three days I told my client it would take me to figure out the problem, I decided to spend a little time working with SAAJ, which is the next layer in Sun's web service stack. It abstracts away the HTTP part of doing XML web services. I figured it was worth a little time to experiment, as it was likely a higher-quality version of the code I was going to wind up writing myself anyway. As it turned out, it was also pretty easy to figure out, and after a few more hours I was able to use my JAXB classes together with the SAAJ stuff to call a simple .NET web service successfully.

The last part of the infrastructure I wrote by hand. It was a fairly simple XSLT that would walk a WSDL document and generate a Java proxy class that would make the SAAJ calls I'd figured out. That took me another few hours. All told I had something workable in around a day and a half. It's not the world's most robust thing right now, but it unblocked the guy who's writing the applet, and that's a Very Good Thing. As we move forward, I'm sure we'll need to add things like better SOAP fault handling, but I don't think that's going to be too terribly difficult either.

The bottom line of all this is that - in the Java world - it appears to have been much easier for me to get up and running with low-level, XML-oriented APIs in Java than with a big OO-oriented toolkit (Tim would be proud). I am, of course, no expert in Java, and the real test will come as we try to use the code I generated in a production application, but I found the experience quite interesting.