[update: fix affiliations]
I just stumbled on an interesting paper from the IEEE Web Services conference last July, Rethinking the Java SOAP Stack (PDF), written by Steve Loughran at HP Laboratories Bristol and Edmund Smith at the University of Edinburgh. Steve and Edmund believe that JAX-RPC (the main Java-based SOAP interface) takes a disasterously wrong approach for a couple of reasons:
- automated Object/XML mapping is badly broken for non-trivial applications, and cannot be fixed; and
- by generating WSDL automatically from Java code, rather than the other way around, JAX-RPC is following a contract-last antipattern.
I agree with them on both points. As I mentioned in my talk at XML 2005, I believe that most attempts to hide XML from developers are doomed because XML really does represent a new way of thinking about information, not just a new way of encoding it. Like the authors, I’ve also noticed that most real-world SOAP implementations end up using document/literal encoding anyway. Here’s a particularly cutting passage from the paper:
We believe that only two categories of web service developer exist: those who are comfortable with XML and want to work with it, and those who aren’t but end up doing so anyway. JAX-RPC provides a sugar-coated wrapping that encourages developers who are relatively unfamiliar with XML to bite. Yet, as anyone who has written a web service of any complexity knows, the XML must be faced and understood eventually. In practise, the task of creating a real web service is made more difficult, not less, by the huge volume of code JAX-RPC introduces into a project.
This is a much bigger issue than JAX-RPC or even SOAP, though. In the end, it points to one of the biggest dividing lines in the XML world, the line between people who think XML is a detail that can be hidden (many big vendors talk that talk) and those who think that it XML is an enabling technology that should be brought into the foreground. Interestingly, the rank and file seem to fall more into the second camp, at least judging by the popularity of raw REST HTTP+XML interfaces among PHP/Perl/Python web site developers.
Glad you like the paper. Note that Ed was actually ad Edinburgh University at the time of writing; I believe NeSC should get some credit for funding him.
regarding doc/lit vs. rpc/enc, the generation-1 stacks were all rpc-encoded; JAX-RPC is essentially built on that world view as is .NET 1.x; it is the only way to serialize a graph of native objects, rather than build a tree-style message. But the future belongs to doc/lit, as it avoids so many interop problems related to interpretation of the soap section 5 encoding.
-steve
Thanks for the comment, Steve. I’ve corrected Ed’s affiliation.