WS-* as a design checklist

Gregor Hohpe weighs in on the WS-AlphabetSoup debate with a new ‘ramble’ that provides some guidance on how to approach the WS-* standards.  He recommends focusing on the intention behind the standards (benefiting from the knowledge and experience of the specification authors) and using them as a checklist for designs. 

… Instead of focusing on [the details of the standard], look at what problem the standard is trying to solve. More likely than not, it is a problem that you are going to have when you go to implement your architectural vision. For example, not knowing where SOAP messages come from and where they are going makes debugging and diagnostics very hard. Not being able to reliably send asynchronous messaging is likely to result in a brittle and not very scaleable "RPC-over-the-network" model.  … I propose to many of my clients to use the WS-* standards as a checklist for their designs. I generally do not recommend they use WS-Addressing or WS-ReliableMessaging (or at least not right out of the gate). I do, however, challenge them by asking, "What is your strategy to track messages in case of error?" or "How do you intend to support asynchronous messaging?" The answer has sometimes little to do with Web Services. For example, the answer to reliable asynchronous messaging might be to use JMS or MQ or another middleware [e.g MSMQ] that ensures guaranteed delivery of asynchronous messages. And that's OK.

I like Gregor’s last point that sometimes the best current solution may not be web services.  This highlights that concept services, or applications based on principles of service orientation, do not have to use web services.  It’s important not to let the WS-* hype and churn delay the creation and deployment of service-oriented systems today.