News

WS-JustSayNo

• By Mike Gunderloy
• September 21, 2004

There's a whole group of specifications, put out by an ever-changing (but usually including Microsoft or IBM) mix of industry partners, that are designed to add new fetures to Web services. With names like WS-Addressing and WS-Security, they're collectively called the WS-* specifications. You may not have noticed, but a couple of new WS-* specifications came out lately: WS-Enumeration for getting items from a list of data held by a Web service, and WS-Transfer for sending a small set of standard verbs over SOAP.

Well, XML guru Tim Bray certainly noticed. In an entry on his weblog he talks about this new development and pronounces himself part of the Loyal Opposition to WS-*. He comments

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.

I must say that I agree with most of this, and certainly with the underlying attitude. There was a time (oh, a year or so ago) when I tried to keep up with the WS-* standards. Taken individually, they make stultifying reading; as a whole, they're enough to bury all but the most dedicated developer. And they pile XML wrapper on XML wrapper, abstraction on abstraction, until the underlying SOAP message is all but lost.

I'm also very wary of treating industry-driven specifications as standards. If you check Microsoft's page of messaging specifications, you'll see that some of them have been submitted to the W3C (but not yet turned into a standard by any means), while many others are just "a public specification." In other words, something a particular group of industry partners is agreeing on for the moment. This is a mighty shaky basis on which to bet your business. If you go ahead and implement some complex Web service according to Microsoft's list of specifications, you're going to be locking yourself out of the chance to migrate to another vendor's stack. That's not a good thing.

Here's my advice for most developers: don't bother to learn all this WS-Stuff. There are three good reasons you shouldn't do more than take a cursory look at a summary of the specifications so you'll know what they cover:

1. Code generation tools and IDEs are rapidly evolving to incorporate the most useful specifications. If you don't need it today, you may be able to just push a button and generate the code tomorrow.
2. Most Web services don't need the features provided by all of the specifications. If you don't need events or transfers or whatever, there's no point in worrying about the relevant specifications.
3. Most important: despite the relentless hype machinery, most code being written today, and most code that will be written in the immediate future, has nothing at all to do with Web services or Service-Oriented Architecture. There are still lots of desktop and Web applications to be written that have no need of a Web service at all. Don't make the mistake of boning up on Web services just so you can stick one in your next project; that's the sort of thinking that led to the last dot-Bomb crash.

One of the powerful concepts in Extreme Programming is YAGNI, which stands for You Aren't Gonna Need It. The idea is simple: implement things when you need them, not when you think you might need them in the future. As far as I'm concerned, this applies to most Web services experiments today. Then again, maybe I'm just getting old.