In a recent blog entry (which is an excellent post), Savas writes about the current problems going on in the WSDL WG. There is indeed a problem here since there are two factions within that group: one that believes that WSDL operations are real and tangible, have expected semantics, and can be reasoned about by consumers; and the other that believes that WSDL level operations are in a sense "virtual" that they simply describe the messages that a service is prepared to exchange and the expected message exchange patterns.
From my previous postings (see: this, and this for example) it's clear that, like Savas, I'm in favour of WSDL as being a contract language that dictates messages and message exchanges, but when I see such obviously bright people arguing against my viewpoint it's clear that something needs further clarification. The major perceived problem can, I think, be illustrated with the following pseudo-WSDL (side note: isn't it a bad sign when everyone uses pseudo-WSDL instead of the real thing?):
MessageX operation1(MessageA);
MessageY operation2(MessageA);
One side of this argument goes something like, "I want to invoke operation1, which means I have to send a MessageA and I expect back a MessageX. I insist on being able to distinguish that it is operation1 that I am invoking because operation1 has some semantics that I want executed, and I absolutely want a MessageX back to tell me that the operation I wanted to execute has indeed executed." In order to achieve this, the WSDL contract needs some way of telling consumers how to encode which operation they want to invoke - that way my service always knows which operation is being invoked and so does the consumer.
Have I been sitting under a rock smoking crack cocaine for the last few years and have missed what is obviously a fundamental truth about Web Services? I don't think so. While the above might seem appealing, don't mug yourself, it's not the way things are. Web Services exist (and indeed evolve) independently of their contracts. To pin your Web Service implementation to your contract makes no sense at all. Certainly the contract must be obeyed at all costs - remember we are doing protocol-based integration here - but the implementation is free to change at any point.
So what does this pseudo-WSDL contract really mean?
It means that if you send a MessageA to my Web Service, it will return to you a MessageX or a MessageY. You might really want it to return a MessageX, in which case you'd better make sure that your MessageA is filled in appropriately (you may need to read the service's documentation for that), but ultimately you might end up with a MessageY instead.
This really isn't a big deal either for humans or tools. You examine the wsdl:interface section of the contract and see what the messages and message exchange patterns are. From that you can determine that you send a MessageA, you can expect a MessageX or a MessageY in response.
To demonstrate this isn't a big deal, let's expand on the original contract. If you look at the example below, you can see that sending a MessageA to my Web Service can get you a MessageX or a MessageY in response. Sending a MessageB will only get you a MessageZ in response, while sending a MessageC will not get you a response at all. To my mind this captures precisely the loosely-coupled spirit of Web Services.
MessageX operation1(MessageA);
MessageY operation2(MessageA);
MessageZ operation3(MessageB);
void operation4(MessageC);
Of course we could just have a single operation which accepts a suitably constrained xsd:choice as its inputs and outputs. This would work just fine too, but wouldn't it be nice if WSDL just did the right thing anyway?
Today's Web Services Super-Hero: Message-Orientation
Today's Web Services Arch-Villain: API-centricity