Internet Alchemy

If you haven’t seen Pete Lacey’s socratic dialogue on the evolution of SOAP then please go and read it straight away. An excerpt to whet your whistle:

Dev: Okay, where’s the spec on this?

SG: Oh, there is no spec. This is just what Microsoft seems to be doing. Looked like a good idea, so now all the cool kids are doing it. However, there is this new thing. I think you’re gonna like it. It’s called the Web Services Interoperability Group, or the WS-I. What they’re doing is trying to remove a lot of the ambiguity in the SOAP and WSDL specs. I know how you like specs.

Dev: So, in other words, the specs were so bad you need a standards body to standardize the standards. Lord. Well, will this solve my interoperability problems?

SG: Oh, yeah. So long as you use a WS-I compliant SOAP stack, avoid using 8/10ths of XML Schema, don’t use any unusual data types, and don’t count on working with WebSphere and Apache Axis.

There must be something in the air because Duncan Cragg has also written some fun and informative articles in the same style for a new series called the REST dialogues: Getting Data and Setting Data. If you want to get a better view of what it means to be resource-oriented then this series looks to be the business.

Sometime you need to make extreme statements to make a subtle point clearer:

It doesn’t matter how easy it is in [awesome VisualStudio/RubyOnRails/Python/IntellijIDEA]. It has to be easy in COBOL.

Robert Sayre on the permathread that is REST vs WS-*

This piece from Dare Obasanjo hot on the heels of the UDDI public registry closure adds weight to my suspicion that SOAP is finally being sidelined into a niche activity.

When I worked on the XML team, I used to interact regularly with the Indigo folks. At the time, I got the impression that they had two clear goals (i) build the world’s best Web services framework built on SOAP & WS-* and (ii) unify the diverse distributed computing offerings produced by Microsoft. As I spent time on my new job I realized that the first goal of Indigo folks didn’t jibe with the reality of how we built services. Despite how much various evangelists and marketing folks have tried to make it seem otherwise, SOAP based Web services aren’t the only Web service on the planet. Technically they aren’t even the most popular. If anything the most popular Web services is RSS which for all intents and purposes is a RESTful Web service. Today, across our division we have services that talk SOAP, RSS, JSON, XML-RPC and even WebDAV. The probability of all of these services being replaced by SOAP-based services is 0.

Mark Nottingham characterises the old REST vs SOAP debate in a different way. Now it’s SOAP vs. HTTP:

you can get any of the listed architectural styles [SOA, RPC, REST] with both SOAP and HTTP.

…[useful table - go see it!]…

When doing so, notice that REST is native in HTTP, and SOAP is native for SOA. Intuitively, I’d rather use HTTP if my chosen architectural style were REST, especially considering how widely deployed and provably interoperable it is. I can choose any number of off-the-shelf, commercial or Open Source intermediaries, caches and libraries to take advantage of REST in HTTP, but the same is not true of REST in SOAP.

My takeaway is: use HTTP if you’re doing REST (document based), use SOAP if you want SOA (message based).