I see my "whatever happened to SOAPBuilders" email on the SOAPBuilders mail list has perked up interest. We may even have a new round, which would be good. It's also raised the problem of "why is SOAP interop still such a mess"?

Unlike Mark, I dont think it is the complexity of the interfaces described in WSDL that causes interop grief.

It is

1. The misguided attempt to seamlessly map XML documents into local structures and method calls
2. The doomed attempt to seamlessly map from local structures and method calls into XML documents
3. All those extra WS-* extensions to do things like reliable communications, async messaging, etc
4. The complete lack of any compliance tests to go with all the various extensions
5. The fact that WS-I killed SOAPbuilders by removing the ability to resolve ambiguities from the implementors, replacing it with a committee that ducked the entire problem of "what subset of XSD to recommend"
6. The use of XSD as the language for describing messages.
7. The fact that WSDL is too hard to write by hand. So many interpo bugreps sent to Axis are resolved 'this is bad WSDL, what can we do?'. [That is why WSDL for REST is a bad idea, because WSDL is the wrong language]

The most poignant metric of interop problems is how Sun and Microsoft are so proud of collaborating so that their SOAP stacks will work together. Why don't you see the same vendors getting together to demo Http client/server or Xml Parser interop? Because if you were that incompetent, people would notice. Also its because Apache, in the form of commons-httpclient and Xerces fixed the problems for Sun.