Paul Prescod links to my to Infinity and Beyond essay as an indication of the problems that SOAP toolkits have in talking to one another.  He's looking at the wrong place.  If you want evidence of problems we have in getting toolkits to talk to one another you need to look here instead.  The point of the essay that he did link to is that you can't get 30 digits of precision for decimal numbers when you interop with .NET if .NET only supports 29.  There is no magic in this world, and so as long as there is diversity, there will be edge cases to bite you in your posterior when you least expect it.

Scanning his other discussions on REST, it appears that he generally uses the term SOAP in a narrowly sense to mean "RPC style SOAP requests over HTTP with SOAP encoding".  But I did see a few gems in there like

too much stuff...the SOAP spec could be split into three or four independent specs that would sink or swim on their own

SOAP is full of optional features. XML philosophy was to drive optional features out as much as possible (we failed once or twice but overall did a much better job of SOAP). Optional features are an interop nightmare.

  5:40:17 PM    

Cool. Sam's WSDL works fine with the .NET Remoting stack too [Peter Drayton]

  3:49:42 PM    

Jon says: I suspect there's more going on here, though. Sam and I both believe that the dynamic nature of scripting languages is not the root cause of WSDL pain. Scripting culture, however, does play a role. Hashtables are popular with scripters because we can build up data structures without having to name all of their parts. This is a major convenience that speeds up development quite a lot. It also has a cost both to us, in terms of future readability, and to others, in terms of maintenance and (when we go over the wire) interop. How to weigh the benefits and costs of anonymous versus named data? And, how to join programming cultures that prefer things one way with cultures that prefer things the other way?

In the long run the scripting culture has to win.  Tightly coupled and brittle interfaces aren't particularly enduring.  We also need a protocol which enables people to initially develop simple interfaces and then gradually evolve them to be more adaptive without breaking deployed clients and servers.

  5:19:39 AM