I forgot about this argument, held by some, including Stefan;
Mark follows up with asking what a successful response to a message in “contract mode” would look like, and that an HTTP 200 response code would not have semantic meaning with regards to the message. Right, it doesn’t – that’s why the response code doesn’t matter as much as the response’s content itself, and why we have things such as WS-ReliableMessaging.
The issue with not using a response code is that it’s impossible to distinguish between success and failure in some cases. Consider a portType/interface/operation of “getLastFault”, whose intend semantics is, as it sounds, to return the last fault sent by this service; how do you know if the fault is a result of trying to find out what the last fault was (which is a real fault), or if that really was the last fault (which isn’t a real fault)? That’s why message metadata needs to be orthogonal to content.
But anyhow, the 200 example was just illustrative of the point that the contract changes depending upon which style of WSDL you’re using. So unless there’s some bit in the message which says which interpretation is intended, then the semantics of that interaction is ambiguous. And even without that bit, the contract itself is ambiguous.
no comment until now