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.