David Orchard has a post entitled Underlying Protocol is a completely leaky abstraction which does a great job of explaining why the notion of protocol independence that is espoused by some SOA proponents is problematic. An example of such thinking is the article Protocol independence in SOA which argues that one can use SOAP to abstract away whether the underlying protocol is SMTP, FTP, HTTP, IIOP or some custom proprietary protocol.

David's post is full of esoteric information from various XML Web Services specs like WSDL, WS-Addressing & SOAP so it may be hard to follow. The gist of his post is captured in this excerpt

Point #1: The myth of protocol independence

This comparison of in vs robust in-only has shown that the application level WSDL MEP will be determined by the underlying protocol, assuming that the underlying protocol's information is fully utilized.

Another possibility is to throw out anything "extra" from the underlying protocol, that is effectively dumbing HTTP down to UDP. In general, Web services using SOAP and WSDL 1.1 has already done that by ignoring the HTTP Operation. The Web services "architecture" has further done that by ignoring the protocol capabilities, such as security, encoding, caching. We could have utilized the capabilities of HTTP and other protocols if we'd agreed how to describe the capabilities, but the "features and properties" work of SOAP 1.2 and WSDL 2.0 looks pretty much DOA.

Corollary to point #1: True protocol independence means dumbing down every protocol to UDP OR a framework for expressing protocol capabilities
I've shown how we are achieving true protocol independence by throwing away everything that makes up HTTP: the operations, status code, response, encodings, security, and all that.

The way SOAP and the various WS-* technologies achieve protocol independence is by basically ignoring the capabilities of the Web (i.e. HTTP and URIs) and re-inventing them in various WS-* specifications. This is one of the reasons I prefer the term Service Oriented Architecture (SOA) for describing these family of technologies than XML Web Services since a core design goal is to not solely target the Web or use XML. One of the simple examples David uses in his post is to point out that HTTP is a request/response protocol where error codes can be returned in the response while protocols like UDP are fire & forget. To build a service that is independent of both protocols one must either ignore the request response capabilities of HTTP (thus treating it like UDP) or build a protocol independent request/response model for UDP (thus treating it like HTTP).

The approach of re-inventing the capabilities of HTTP in the various WS-* specification does cause confusion and irritation amongst developers who plan to only use these technologies on the Web. For example, in a recent post entitled Is WS-MetadataExchange really necessary? Phil Windley argues that WS-MetadataExchange which is a SOAP based mechanism for retrieving WSDL, Policy and XSD files for a service endpoint can be can be replaced by URI such as http://www.example.com/service_path?meta=wsdl . In a response entitled WS-MetadataExchange Don Box points out that one of the reasons the aforementioned specification exists is so that metadata discovery can happen in a protocol agnostic manner. There have been similar discussions about WS-Addressing and HTTP which are summed up rather well in Stefan Tilkov's posts WS-Addressing and Protocol Independence and  Mapping WS-Addressing to HTTP.

The main message here is that there is no free lunch. If developers want to build protocol independent services then there is an added complexity cost which hardly seems justified if one can simply build XML Web services as opposed to SOAs.  

One of the things I've been nagging the XML Web Services folks at Microsoft about since getting to MSN is to do a better job of targetting folks who want to build XML web services as opposed to focusing all their energy on SOA scenarios only. I've tried to frame this as distinguishing between 'enterprise' scenarios and 'web' scenarios but would love to hear more articulate ways of phrasing the distinction.


 

Categories: XML Web Services
Tracked by:
"I bookmark del giorno #7" (Lorenzo Barbieri @ UGIblogs!) [Trackback]
"I bookmark del giorno #7" (Lorenzo Barbieri @ UGIblogs!) [Trackback]
"Protocol Independence, SOAP and Leaky Abstractions" (Dare Obasanjo aka Carnage4... [Trackback]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d727f91c-56a3-40d6-9c45-25... [Pingback]
http://zabivwn.net/colorado/sitemap1.html [Pingback]
http://toxgxlv.net/ebay/sitemap1.html [Pingback]
http://box405.bluehost.com/~dugablog/sitemap2.html [Pingback]
http://yftbsy1.net/nascar/sitemap1.html [Pingback]
http://fwmwly7.net/connecticut/sitemap1.html [Pingback]
http://weujmru.net/estate/sitemap1.html [Pingback]
http://restablog.dreamhosters.com/photo/sitemap1.html [Pingback]
http://gk3hen1.net/03/sitemap1.html [Pingback]
http://lx2rnws.net/pets/sitemap1.html [Pingback]
http://akytft5.net/sitemap1.html [Pingback]
http://henres.site.io [Pingback]
http://gator393.hostgator.com/~rocata/sitemap2.html [Pingback]
http://fipmqpn.net/02/sitemap1.html [Pingback]
http://fongyf6.net/ebay/sitemap1.php [Pingback]
http://node22.myserverhosts.com/~boosters/games/sitemap1.html [Pingback]
http://kiva.startlogic.com/sitemap1.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap3.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap4.html [Pingback]
http://gator413.hostgator.com/~digital/law/sitemap1.html [Pingback]
http://fastblog.sc101.info/auction/sitemap1.html [Pingback]
http://bbgicfz.net/sitemap1.html [Pingback]
http://lyxlyiy.net/sofa/index.html [Pingback]
http://mwtobvc.net/05/index.html [Pingback]
http://cgvostw.net/bmw/sitemap1.php [Pingback]
http://ik6bcb7.net/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap2.html [Pingback]
http://d579737.u108.floridaserver.com/sitemap2.html [Pingback]
http://gator442.hostgator.com/~hockteam/ebay/sitemap1.html [Pingback]
http://gator442.hostgator.com/~hockteam/games/sitemap1.html [Pingback]

Tuesday, May 10, 2005 6:31:02 PM (GMT Daylight Time, UTC+01:00)
Was there any actual *demand* for protocol independence (and I don't from people who just thought it was a good idea, I mean from people who were finding HTTP a limitation)?
I'm curious about that one, and honestly don't know myself.
I hope it's not just something else in the vein of people spending ages writing database abstraction layers for internal applications that will never, ever use anything other than SQL Server.
Tuesday, May 10, 2005 8:43:40 PM (GMT Daylight Time, UTC+01:00)
"...or build a protocol independent request/response model for UDP (thus treating it like HTTP)."

SIP is a good candidate for that, I'd say, but it's way more complex than HTTP, and it would be too tempting to use the features SIP provides, thus wrecking the protocol independence dream. It doesn't really make sense to go to all that trouble if all you want to do is send xml across the web.
Wednesday, May 11, 2005 2:02:16 PM (GMT Daylight Time, UTC+01:00)
The demand I hear for protocol independence originates from people with an existing investment in a messaging infrastructure based upon protocols such as MSMQ, MQSeries, Sonic MQ, etc. Here messages hop between systems, often being queued before being processed. By the time an application or a pipeline process sees the message, any context communicated at the transport level is long-gone. Hence specifications such as WS-Addressing and WS-RM* are more interesting in a SOAP architecture than anything HTTP or any other single transport could have to offer. Having said all that, hats off to you Dare for pushing more Web like approaches within Microsoft.
Comments are closed.