What were we thinking?

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.

If the Internet vision of "IP over everything and everything over IP" has any validity, and I think it does, then it's a pretty safe bet that we will also see the Web vision of "HTTP over everything" (though I'm not nearly as sure of the reverse "everything over HTTP"). So its only a matter of time when we can count on HTTP support on virtually ever endpoint, from mainframe to handset. (Note that just about every appliance that need to be configured now supports HTTP, e.g., your Linksys Wireless Access Point.) Then the only real argument is about how to make HTTP more robust: XML headers inside the HTTP envelope (the SOAP approach) or evolving the HTTP envelope itself (the waka approach). With the ever slowing pace of SOAP header ratification, interop certification, and implementation, I'm getting a lot more excited about waka-like dark horse.

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. (I thought there had once been standardized SOAP binding for at least SMTP as well, but in looking back at the SOAP 1.1 and 1.2 specs, I see I was mistaken. SMTP is used as an example in the SOAP 1.2 primer, but no standard binding was ever defined.) Yes, there's lots of talk about how SOAP can be bound to different transports, and there's even a fair number of vendor implementations that support alternative bindings, but in my experience there are woefully few organizations actually doing it.

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 (or in the case of WSDL native SOAP). (WSDL currently only standardizes binding to SOAP and HTTP.) Doing so would also do a lot towards narrowing the rift between the RESTafarians who see the Web (especially HTTP) as a good enough application architecture and the WS-* proponents who sometimes appear to believe that WS-* is a hostile overlay of the Web.

Comments

[Jacek]

Regarding the so-called SMTP binding, the W3C has produced a Note (not a Recommendation, but still intended to be useful) of SOAP Email Binding - see http://www.w3.org/TR/2002/NOTE-soap12-email-20020626

As one of the authors, I fought hard to remove SMTP from the title, because the binding is in no way specific to SMTP, (it could have been called SMTP/IMAP/POP binding to be more , but still not fully, correct). Now I see that with that incorrect name the document would apparently be easier to find...