It's been a while since we've had a good old-fashioned dust-up from the Web Services suck pantomime (hint: oh no they don't). Mark (who else?) writes:
The concept of a "SOAP binding" is prima facie broken because it necessarily requires treating underlying protocols as transport protocols, as if the SOAP envelope was actually a SOAP message (hint:it isn't).
Well stone me if I don't agree with the first half of that - sort of. The concept of a SOAP binding is a bit out of kilter with WS-Addressing since in my MESTian head, WS-Addressing is just a standard way of putting addressing information inside the SOAP envelope (I'm planning to figure out how to constrain WS-Addressing in a MEST/SSDL sense, will write more on that later). As such SOAP is the only meaningful place to host WS-Addressing and so a SOAP binding shouldn't be necessary - WS-Addressing should be SOAP native. Other technologies already have their own addressing abstractions (and contract languages for that matter...).
However the notion of a SOAP envelope not being a message is very wrong. A SOAP envelope is a message at this level of abstraction, and this message is transferred using some underlying application-specific or transport protocol. From a SOAP point of view (ignoring the horrid placating text on Web-friendliness in the SOAP spec) anything underneath the SOAP layer is transport which is a good thing. WS-Addressing makes this good thing possible. No longer do I have to peek under the covers and manipulate underlying transport addressing information directly, now that will be taken care of by WS-Addressing implementations.
Sorry Mark but I will continue to push for what you'd see as an abuse of HTTP because the architectural constraints imposed by SOAP and WS-Addressing are orthogonal to your concerns. I know you care dearly for all of us poor misguided souls who haven't embraced the Web yet, but maybe we need to get burned before we have our epiphanies.
C'mon, the Web is just so, well, 1990s...:-P