A lot of energy is being uselessly expended on debating whether the WS-* stack of web services specifications is a waste of time or not. Here's a sampling of points of view from "The Loyal WS-Opposition," who I firmly believe have got it completely wrong; and I'll explain why later in this posting.
Tim Bray's manifesto for The Loyal WS-Opposition has been quoted all over the place, especially this statement: "No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it's going to be hard to understand, hard to implement, hard to interoperate, and hard to secure." Tim followed up with a WS-Pagecount that seems to find a tally of 1000+ pages of WS-specifications (excluding those that he describes as "WS-Gone but not WS-Forgotten"). Which is a lot, if you have to implement them all at once.
Mike Gunderloy of ADTmag.com follows up with a piece entitled WS-JustSayNo. "Here's my advice for most developers: don't bother to learn all this WS-Stuff," he says. "One of the powerful concepts in Extreme Programming is YAGNI, which stands for You Aren't Gonna Need It."
Simon St Laurent chimes in on his O'Reilly weblog, quoting several other contributors to the debate, and asking Are Web Services receding?: "A large number of programmers and users aren't actually enterprise developers we have no more need of WS-Transfer than we have of an S/390 running a dedicated message queue system. For the most part, Web Services and the WS-* set of specifications address problems many people just plain don't have." I found this an interesting statement considering that a significant number of early adopters of web services are doing so in order to connect to mainframe systems, as several of thisweek's news announcements attest. Even if the vast majority of web services users don't need all the capabilities of the WS-* stack, does that mean the significant minority who link transactions into mainframes on behalf of all of us should be denied the capabilities they need?
OK, the reason all these opponents and critics of WS-* have got it wrong is that they've missed the crucial point, which Eric Newocomer put very succinctly: "Maybe it's just a case of using the simple format to do simple things and a complex format to do complex things."
Luis Cabrera, Christopher Kurt and Don Box have co-authored an invaluable paper this month, called An Introduction to the Web Services Architecture and Its Specifications. It describes all of the key elements in the WS-* stack and why they're there. This is all excellent reference information. But the crucial statement comes on the first page: "The implications of autonomy are central to the architecture."
In other words, it's up to you what you use, and what you don't use. If you don't need any of the WS-* stack, then fine. Don't require any of it in your WSDL definition. Actually, don't even bother to write a WSDL definition. Just publish a URI. It's up to you. Your service is autonomous. It will still interoperate with any other endpoint that's comfortable interacting with a URI that makes no service warranty.
This is why the debate between WS-* and its would-be nemesis REST (ie XML over HTTP without even SOAP let alone any of its WS-* frippery) is a futile distraction. The whole point of SOA is that every participant can set their own rules. In fact, the reason there are so many separate WS-* specifications is that each one is meant to be optional. Some transactions will need them, others won't, and all of that can be specified in the service contracts associated with each of those transactions. That's the essence of WS-LooseCoupling.
And no, WS-LooseCoupling isn't another WS-* spec. It's just an attitude of mind, a principle: do what you like. In a loosely coupled service oriented architecture, you have a choice. The rich tapestry of the WS-* stack is there if you need it. If you don't, you're not obliged to use it. Take it or leave it. But once you've made your choice, don't try to impose your preferences on other participants. They're free agents too. It's all about autonomy.