The Ancient Art of Programming

In my previous post, I talked about exporting Spring business interfaces via SOAP to integrate with a .NET client. I said:

How hard can it be, right?

Well, as it turned out, it is pretty hard. While the basic idea of sending XML messages across HTTP is simple, the SOAP spec is not. It really suffers from specification creep.

Instead of making matters easier (like Microsoft has done with its implementation of the SOAP standard), Sun has decided to make matters even harder. I found four (!) specifications which relate to SOAP and Java. These are:

1. JAX-RPC, which focusses on the J2EE side of things,
2. JAXM, which is somewhat more lightweight,
3. SAAJ, which provides the standard API to handle SOAP messages, and finally
4. JWSDL, which provides the standard API to generate WSDLs.

Don’t ask me how these standards relate to one another. I honestly don’t know.

Most of these specs only define interfaces, so you also have to find someone crazy enough to implement them. (Which reminds me: I would love to be a spec writer at Sun. Just designing interfaces all day, and let the mere mortals implement them). No wonder Axis is so complicated, it is because of the SOAP and JAX-RPC specs!

In the end, I got so fed up with SOAP, that I decided to look into a totally different way of exposing Web Services: XML-RPC. What a great spec! It fits on one sheet of paper!

Withing 15 minutes, I had a working XmlRpcServiceExporter, which exported the business interface of my Spring-managed bean to a .NET client. On the Java server-side, I used Apaches XML-RPC implementation; on the .NET client-side, I used Charles Cook’s excellent XML-RPC.NET.

The Apache XML-RPC library does seem to have one problem, though: it implements struct values as Hashtable objects, and not as JavaBeans. XML-RPC.NET does convert the properties and fields of a class to values in a structs, like one expects.