John Evdemon just published 2 articles on the principles of web service design.

The first one is titled Principles of Service Design: Service Patterns and Anti-Patterns and in my opinion should be required reading for anyone who is new to web service development. Specifically, anyone new to building web services should focus on his explanation of the 4 tenets of service orientation, and the anti-patterns - this is good stuff - but if you've been staying up to date on web service architecture and development, you won't read much you haven't read/heard before. If you think you're pretty up-to-speed on web services, just breeze through those parts and check out the patterns - they tend to be more specialized.

The second article is titled Principles of Service Design: Service Versioning. This article was of particular intereste to me since I've done quite a lot of thinking about the right approach to versioning web services. If you haven't thought much about how you're going to version your services, definitely check out this article. John does a good job of getting you up to speed on the issues quickly - this is a difficult problem to solve in an elegant way.

This is something you might not pick up on while reading the article. Notice how John does not consider the use of strings or XML nodes an option for message versioning. He doesn't consider this because it's not recommended. Coupling is not loose or tight - there are varying degrees of it. Typing web service messages as strings is too loose, but not providing an extension mechanism or open content model is too tight. John is recommending a nice balance.

I didn't expect the article to effectively say, "here is how you should version your web services," which it doesn't, but, I like John's approach. He effectively says, "here are the issues and here are some principles that should guide your decision making." This is about the most you can ask for at this point. No one in the entire industry has come up with a definitive, elegant mechanism that addresses versioning for all types of services. I would like to see that happen someday. I'm currently working on some tooling that may result in great strides to this end. More later ;-)