Generic Web Services Evolution

Our question this week comes on the heels of last week's podcast REST vs. Web Services. Dean asks:

"Hi Udi,

What are the reasons you are seeing a more generic API, rather than one that is more strongly typed?"

Well, Dean, glad you liked it. To answer your question, I think we need to say a word or two about what a service exposes.

In the API you mentioned, there are 2 elements in plain view, and one that's hidden. Those that can be seen are the message contract and operation contract, to use the terms Microsoft has coined. The additional element that isn't visible is the endpoint where the service exposes this operation.

When I said that I see more generic APIs evolving, I meant that the only difference between one operation and another was the message types, which led to a single operation supporting top-level message types - all request message types "inheriting" from RequestMsg, and all response message types "inheriting" from ResponseMsg.

This would be looser typed than exposing a specific operation for each pair of message types, unless the message types were part of the contract. No one said that the WSDL file is the only element of the contract. You could just as easily pass an XSD file that contained all the message types along with a generic WSDL file.

As to the endpoint, you could have all the service's endpoints support the same generic WSDL file, but have a different XSD file for each one - of course you'd have to pass this information along to anyone who wanted to use those endpoints.

Finally, I would say that I'm not seeing much done in terms of asynchronous communications patterns with Web Services. It's probably because WSDL just doesn't support pub/sub, or the Return Address pattern. In my opinion, for Web Services to bring the greatest value to organizations, they need to, at the very least, support the rich messaging patterns we've come accustomed to in EAI.

Posted by Udi Dahan at 06:39 AM  Permalink