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:
- 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.
- 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.
- 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.
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.