Web services alphabet soup

Here's one popular definition of insanity: "Do the same thing, expecting a different result." Now consider the following partial list of proposed standards for Web services: WS-Addressing, WS-AtomicTransaction, WS-Attachments, WS-Context, WS-Coordination, WS-Eventing, WS-Federation, WS-Reliability, WS-ReliableMessaging, WS-Routing, WS-SecureConversation, WS-Security, WS-SecurityPolicy, WS-Transaction, and WS-Trust.

That's just the WS series; there's also XML 1.0, XML Schema, SOAP, WSDL, UDDI, XML-DSig, XML-Encryption, XKMS, SAML, XACML, ebXML, BPEL4WS, WSRP, and a partridge in a pear tree. Is this nuts? Some people think so.

The watchwords of XML Web services were the watchwords of the Web: simplicity and universality. But as the specs multiply like weeds, it's fair to ask if we're now just reinventing CORBA and DCOM, doing the same old thing and crazily hoping for a different result.

I recently put the question to John Shewchuk. He's an architect on the Indigo team at Microsoft, working on Longhorn's next-generation Web-services-oriented communication subsystem, and a co-author of a bunch of the WS specs. According to Shewchuk, we're not just reliving the past.

There is something qualitatively different about the WS menagerie: modularity. "We took a building block approach," Shewchuk says. "WS-Security is a small 10-page spec. You could knock out an implementation over the weekend in Perl or Python." That's because WS-Security doesn't try to do everything; it's just a framework for securing messages. Likewise, WS-Addressing paves the way for asynchronous, transport-neutral communication. And WS-Trust lays the groundwork for a range of security protocols.

What makes this modular approach possible, Shewchuk says, is XML itself. "Before XML, what always ended up destroying our protocol stacks was fixed-offset dependencies." At the time, you couldn't modify or extend packets without breakage. But XML packets are flexible, accordion-like structures. Individually they can grow; collectively they can be rearranged. This "composable architecture," Shewchuk argues, is something new in the realm of communication protocols.

Good answer. But we're still left with a zoo of protocols that, for most developers, create severe cognitive overload. It's one thing to say that a secure transacted session can be composed out of these modular parts, but quite another to actually achieve that effect. Shewchuk agrees. The solution, he suggests, is tooling that enables a declarative style of programming.

This idea dates back to MTS (Microsoft Transaction Server). Before COM+ and J2EE, MTS pioneered the notion that you need not write lines of code to invoke services such as transactions or object pooling. Instead, a programmer could invoke these services with simple attribute declarations. Or an administrator could achieve the same effect by setting attributes in a management console.

When Indigo ships -- and by the way, it's expected to land ahead of Longhorn itself and to show up on today's versions of Windows as well as tomorrow's -- the goal is to offer tools that use this approach to tame the kudzu-like proliferation of standards. "In Indigo, it boils down to attributes," Shewchuk says. "You tell the run time you want confidentiality, longevity, and reliability, and it uses the composable architecture to translate that into a configuration on an execution pipeline."

You've got to love the vision. Is it a recipe for WS-WorldPeace? That will depend on Microsoft's commitment to base standards, which so far looks more solid in Indigo than in Avalan or WinFS. It will also depend on everybody else figuring out what Microsoft has always known: packaging technology, in ways that make sense to average developers, matters a lot.