Mike Champion argues that XSD is a problem, but you encounter it in REST-land too, so people should stop making snide comments about the lack of a need for an HttpBuilders mailing list.

I was one of the people making such comments. For reference, java.net.HttpUrlConnection has been broken in many ways, such as its cookie handling, maybe redirect processing, fault handling (access to the response text after an http error code varied on the extension of the URL, not the mime type). I even encountered it downgrading the size of the content-length header if it got less back than promised. And then there is authentication, especially NTLM and message digest. But generally it works. One of the key features is that its easy to debug HTTP problems: point a web page at the same URL, and see what you get back. Work with SOAP, and you are doing tracelogs.

Mike also thinks that XSD interop is now mostly solved (!), and that the language hits the sweet spot for O/X binding. I disagree with both of these points. We cannot reliably send an xsd:dateTime between two endpoints on the same machine without its timezone getting confused, attachments are something you need to negotiate on, and nobody even understands why xsd:nil actually exists, since its a way of declaring inline "I choose to break this bits of the public schema, get over it".

Furthermore, it is the attempts of the SOAP stacks to work backwards from native implementation classes to an interoperable XSD/WSDL interface that causes so many problems, not least because it makes end users think they really are sharing native objects over the wire.

In REST-land, few people work with XSD, even less try to seamlessly map from the schema to native types, and nobody expects the runtime to infer a REST state model from implementation classes. Yet despite the lack of all this integration, REST appears to work better.

As such, SOAP is retreating to the world of "Enterprise Grade" systems. This is still large and exceedingly well-funded, but it is a backing off from the original vision, which was WS-* as the way that programs talked to publicly provided services from third parties that brokers would find for you. I'd watch out there: the smaller the nice that WS-* can lay claim to, the less relevant it becomes. Just as Hibernate killed EJB-classic, so can lightweight protocols kill WS-*.

One thing to think about here is Dan Diephouse's proposal for a kind of WS-* 2.0: SOAP+RelaxNG+SomethingBetterThanWSDL+WS-*.. If we have to work with SOAP, then I think this is how it will survive:

1. Use RelaxNG as the type language. No more xsd:nil problems.
2. Stop ignoring the HTTP layer underneath, and integrate better with HTTP error codes, and things like redirects. Reported errors should include http codes, headers and text
3. View XSD as the Cobol of XML.
4. Use XMPP as the back channel. Not WS-Eventing, or WS-Notification. Or let people poll. It actually works quite well when the number of polling clients is very low, as it probably is for most communications between two nodes, and it works around the whole firewall problem. I also believe that by decoupling the links between client and server more, you avoid the intermingled object model that is the curse of large distributed object applications.
5. Replace WSDL with something people can read and write. I'd look at SSDL, whose cover artwork apparently includes someone writing XML with a fountain pen. However, it ought to have a human-friendly syntax, just at RelaxNG does.
6. Stabilise or kill WS-Addressing. WS-A is the recurring bane of my life. People ask me why, and I have to point them at code that tries to move data to and from the various versions of wsa:epr on the wire. URLs, that's all you should need. If you want async two-way comms, then give a URL for responses; an xmpp: one for xmpp responses.
7. Sort out attachments.

Now, back to my WS-RF based, Axis2 hosted application. Let it not be said that I critique SOAP/WSDL and the like for ideological grounds. I critique it because I have to use it, and it sucks.