Good discussion (as usual) of design issues (incl design conflicts) between SOAP and WSDL MEPs. Also points out that apparently SOAP envelopes don’t contain MEP metadata, so SOAP intermediaries cannot tell be examining a SOAP envelope which MEP it is part of! This seems like a huge design oversight and proof of how little experience we have with protocols with first-class treatment of intermediaries. Perhaps SOAP and WSDL have bitten off more than the critcal mass of programmers can chew on.
It’s a feature, not a bug! I can’t find it, but I remember when MEPs were introduced back in the early days of XMLP, that I expressed concern that MEP information would find its way into the message.
The problem is that application protocols determine the “MEP”, not the SOAP envelope. For example, if the transfer protocol is HTTP then you know you’re in the middle of a request-response interaction because it’s HTTP. Want to use HTTP with a new MEP that enables, say, out-of-order responses? Tough! HTTP doesn’t support it. Well, I suppose you could define an HTTP extension to support it, but you still don’t need anything in the SOAP envelope.
It’s just another example of how protocol independence really is the root of all evil in Web services.
As for Nick’s suggestion that we lack experience with protocols with first-class treatment of intermediaries, I disagree; as an industry, we have a huge amount of experience with them, in particular with SMTP and HTTP, both of which have been deployed for ages, and at massive scale. Unfortunately, the overlap between those with that knowledge and experience, and advocates of WS-*, is essentially the empty set. 8-(