Partager via

Understanding the Place of POX, SOAP and WS-* in Building XML Web Services

  • Article

This morning I saw a post by Tim Bray entitled Another Loyal Oppositionist where he pointed to a post by James Governor stating that Microsoft is ignoring the demand for toolkits that support plain old XML over HTTP and instead focusing on SOAP-based XML Web Services and the WS-* family of specifications. Before I could respond I saw that Mike Champion had already beat me to the punch with his post  MS Ignoring developer demand for REST tools? where he writes

The long running PR battle is heating up again between those who advocate the implementation of service architectures [1] "RESTfully" using XML transferred via HTTP, vs those who work with SOAP, WSDL, and the specs built on them known as "WS-*".  The item that finally got me to blog about this painful [2] subject was James Governor's SOAP is boring, wake up Big Vendors or get niched

Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. ...Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls.

Yesterday my partner Stephen issued a wake up call for middleware and tools vendors - give developers what they want , not what you think they should have. ...

One big question is why haven't IBM and Microsoft responded? The obvious answer is vested interest. When you have "bet the company" on a technology stack its kind of a drag to have to respond to something else.

A few thoughts: For one thing, I'd note that Microsoft  has responded to this need ... in about 1999.  The XMLHTTPRequest object implemented since the second version of the MSXML library provides such a powerful and convenient way to use XML and HTTP together that this API has been implemented in competing platforms, and was featured in an XML.com article just last week.   Forgive us for not touting Microsoft's support for this newfangled "RESTful" approach, I guess people here thought it was old news :-)

When I read James Governor's post, I also wondered what he was expecting from a toolkit for supporting XML Web Services that just used POX (plain old XML). We've shipped multiple XML APIs and have libraries for working with HTTP in the .NET Framework. In MSXML, we shipped XMLHTTP which recently started making headlines again because Google has been using it heavily in their recent web applications such as Google Suggest. Microsoft has and will continue to ship libraries and tools that make it easier for developers to work with plain old XML over HTTP.

SOAP and the WS-* family of specifications target developer problems with more sophisticated requirements and needs than can be satisfied by simply using POX. As I stated in my recent post  On Interoperability and Tim Ewald's 3 Web Services Stacks

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.

Given that Don Box linked to the above post and commented favorably on it I believe this makes it clear that we at Microsoft understand that POX, SOAP, and WS-* each have a part to play in the world of XML Web services.

Comments

  • Anonymous
    February 15, 2005
    The comment has been removed
  • Anonymous
    February 15, 2005
    thanks dare. a POX on your house. i will be writing a coda. i was riffing on the point about chosen access mechanisms. i think if 80% of folks are choosing POX or REST or something other than wshful calls it is indeed a good question what the access mechanism actually is.

    i still see loads of "web services" definitions that only talk to WS-I. there was one in businessweek for example, just last week. i was guilty of this in the 2k timeframe, and something i am attempting to redress.

    I am happy for MS to make a strong claim to web services pluralism. that is excellent. your definition does not require SOAP, which was my conclusion.

  • Anonymous
    February 18, 2005
    I like to think i am more of a disloyal opposionist.. ;-) some keys to consider in my earlier post on SOAP and REST - those are a. niche - my intention was never to say SOAP is dead, merely...
  • Anonymous
    March 05, 2005
    still see loads of "web services" definitions that only talk to WS-I. there was one in businessweek for example, just last week. i was guilty of this in the 2k timeframe, and something i am attempting to redress
  • Anonymous
    May 03, 2007
    Sorry for the title, couldn't resist. I found this; "SOAP is Comatose But Not Officially Dead" followed...