Tim Ewald has a post entitled My 3 Web Services Stacks where he writes

The point Chris was making was that you created a COM class, your choice of data type determined who could use your component. In other words, your choice affected how far your code could reach. There will be a similar split in the Web services world, hence the title of this post. This time though the spin will be a little different. It won't focus on data format so much (it's all just XML), but on behavior. To wit, “My 3 Web Service Stacks“:

First, there is basic SOAP over HTTP described with WSDL and XSD. It hits a sweet spot for developers who want tools to hide XML details but is still simple enough to implement everywhere. Then there is WS-*, which offers richer functionality but is harder to implement and will not be supported by all products, especially legacy systems. Finally, there are toolkit specific features like BEA's idiom for async messaging over HTTP using a header to convey a callback URL, Iona's Artix support for a CORBA binding, or Microsoft's Indigo support for binary messaging.

In this world, your choice of feature will decide how far you can reach: to everyone, to everyone using WS-* enabled tools and infrastructure, or only to others using the same toolkit you are.

I completely agree with this and in fact back when I was on the XML team I used to be frustrated with the fact that the given all the reams of text coming out of the XML Web Services Developer Center on MSDN Microsoft never did a good job of explaining this to developers. Of course, this would require admitting that many developers don't require the functionality of the WS-* specs and due to their complexity in certain cases this would actually hamper interoperability compared to plain old SOAP (aka POS). To some this may contradict Bill Gates's statements on interoperability in his recent executive memo Building Software That Is Interoperable By Design  where he wrote

The XML-based architecture for Web services, known as WS-* ("WS-Star"), is being developed in close collaboration with dozens of other companies in the industry including IBM, Sun, Oracle and BEA. This standard set of protocols significantly reduces the cost and complexity of connecting disparate systems, and it enables interoperability not just within the four walls of an organization, but also across the globe. In mid-2003, Forrester Research said that up to a "ten-fold improvement in integration costs will come from service-oriented architectures that use standard software plumbing." 

However context is everything. Replacing a world of distributed applications written with DCOM, CORBA, Java RMI, etc with one where they are written using the WS-* protocols is a step in the right direction. I completely agree that it leads to better interoperability across technologies produced by the big vendors who are using incompatible technologies today.

But when your plan is to reach as many parties as possible one should favor simpler Web services technologies like plain old SOAP or just plain old XML (aka POX). Plain old XML doesn't necessarily mean following the principles of REST either. After all a number of successful plain old XML services on the Web don't follow these principles to the letter. For example, Joe Gregorio pointed out in his article Amazon's Simple Queue Service that Amazon's Queueing Service violated these principles. In Sam Ruby's post entitled Vacant Space he points out that plain old XML web services exposed by Bloglines and del.icio.us aren't RESTful either.

When building distributed applications using XML, one should always keep in mind the 3 web service stacks. My day job now involves designing XML web services for both internal and external consumption so I'll probably start writing more about web services in the coming months.