Nick Gall has a blog post entitled What were we thinking? where he writes

It just struck me, after 5+ years of analyzing the ins and outs of SOAP, how little need there has turned out to be for the SOAP binding model (i.e., binding SOAP onto various "transport" protocols). If some endpoint is going to go to all the trouble of enabling processing of URIs and XML (a prerequisite for processing the SOAP envelope), what are the chances that said endpoint would not go ahead and enable HTTP processing? The scenario of a mainframe endpoint that is able to process a SOAP envelope, but is unable to process HTTP to receive the envelope strikes me as ludicrous.
...
So who really cares that SOAP is able to be bound to MQ or IIOP or SMTP, today? Apparently, very few--since there has been virtually no progress towards standardizing any SOAP binding other than to HTTP for years.
...
Accordingly, it seems to me that the WS-* stack could be made a lot less complex for the average developer if the SOAP and WSDL binding models were simply deprecated and replaced with simpler "native HTTP" binding

This is one of those blog posts where I simultaneously agree and disagree with the author. I agree that a lot of the complexity in WS-*/SOAP/WSDL/etc has to do with the notion of "protocol independence". As I mentioned in a previous post entitled Protocol Independence is a Leaky Abstraction, 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 leads to a lot of unnecessary complexity and layering when you are already using HTTP as the transport protocol (i.e. the most common usage of SOAP).

On the flip side, there is something to be said for being able to use one distributed application model and support multiple protocols. For example, if you read the Windows Communication Foundation whitepaper you'll see it mentioned that WCF supports sending messages via HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ). I've actually been working on using this functionality in some of our internal Windows Live platform services since the performance benefits of using TCP for communications over SOAP/HTTP are considerable. However we'll still have SOAP/HTTP end points since that is the lowest common denominator that SOAP-based services that interact with our services understand. In addition, I'd like to see some straight up PlainOldXml/HTTP or RESTful end points as well.

One of the main problems we've faced in our evaluation of moving to multiprotocol SOAP services is how much of a leaky abstraction the "protocol independent" nature of SOAP tends to be in real life. My favorite issue thus far is that we actually use HTTP redirects in our current SOAP web services. Guess what? There is no "protocol independent" WS-Redirect specification. So we have to roll our own solution for non-HTTP protocols.

We've hit a couple of other minor issues but in general the support we've gotten from Omri, Doug Purdy and others on the WCF team has been great. In fact, I've started to lose some of my skepticism about the WS-* family of technologies. I still think they are overkill for the Web though. ;)


 

Friday, August 25, 2006 11:46:49 PM (GMT Daylight Time, UTC+01:00)
SMTP is being overlooked as a good way to implement notifications.
pwb
Saturday, August 26, 2006 1:56:52 AM (GMT Daylight Time, UTC+01:00)
"On the flip side, there is something to be said for being able to use one distributed application model and support multiple protocols. For example, if you read the Windows Communication Foundation whitepaper you'll see it mentioned that WCF supports sending messages via HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ)."

No. That isn't it. If you really want multi-protocol support or protocol gateways, drop down below HTTP and target BEEP. It's the only protocol design toolkit you'll need. I think it's turned out there's no real demand for standardisation at that layer - the state of SOAP, JXTA and BEEP speak against it. TCP/IP is uniform packer transport; anything that HTTP can't solve can be dealt with by SMTP or XMPP. I think we're in a period where application transfer is crystalising; ie HTTP and SMTP are going to get baked into the network the way TCP/IP has.
Saturday, August 26, 2006 8:33:03 AM (GMT Daylight Time, UTC+01:00)
I like this site. Very interesting.
Sunday, August 27, 2006 8:22:16 PM (GMT Daylight Time, UTC+01:00)
I thought this post was about Snakes on a Plane. Redo please.
ninja tamer
Sunday, August 27, 2006 9:04:21 PM (GMT Daylight Time, UTC+01:00)
In the enterprise we certainly saw a need to move messages on multiple transports. This caused a lot of grief but it was important. HTTP is a chatty protocol that provides no native support for queuing. So it's common in enterprise land to use HTTP for external interfaces and then using queuing systems internally. The end result is that a single message ends up traveling over multiple transports. What's interesting is that in practice I almost never saw people make serious use of WS-* for these scenarios. In fact, in my personal experience, the most common usage pattern was POX. That turned out to work just fine in practice. The reason I believe this is so is that most of the queuing systems are addressed based so URLs got turned into queue addresses. These are obvious downsides to this approach but in practice it worked well for many multi-step enterprise workflows.
Comments are closed.