Rocky Lhotka has an interesting article about SO Design, and how the current state of affairs of SOA implementations and the tools we use to develop them. Basically he says that because of how the tools deal with web services, the way we develop web services is flawed, and we should be using covenants on top of contracts.

If you don't read the article, here's what he's talking about. A contract is the API you use to call the web service, where as the covenant is the agreement you make - i.e., if you give me this, I will do that. He's basically saying that the API shouldn't be strongly typed. Basically, he's saying your API should be:

responseMessage = MyFunction(requestMessage);

Then you can put whatever you want in the requestMessage and get whatever you want back in the responseMessage. It's an interesting idea. Your service API never changes, but you can allow newer clients to use your service. You just specify a new covenant.

UPDATE: I started writing this, and was going to talk about the problems with using an untyped requestMessage and responseMessage, but reading Rocky's blog, I came across his latest post, where he linked to an article on SRT Solutions that talks about how to use abstract classes in web services and accomplish the above solution and get type safety. Very nice.

Coincidentally, the article on SRT Solutions was written by Bill Wagner, who works with Josh Holmes. I posted about a presentation Josh was doing in Grand Rapids back in December, and if I remember correctly, he actually came over to my desk and thanked me for the link. I had completely forgotten about that until I found this article today!