Building SOA your way

A fault line runs beneath the groundswell that began a few years ago with XML Web services and continues today as SOA (service-oriented architecture). True, nearly everyone agrees that XML messaging is the right way to implement low-level, platform-agnostic services that can be composed into higher-level services that support enterprises business functions. Yet, here’s also a sense that the standards process has run amok.

IBM, Microsoft, and others have proposed so many Web services standards that a new collective noun had to be invented: WS-* (pronounced “WS star” or sometimes “WS splat”). The asterisk is a wild card that can stand for Addressing, Eventing, Policy, Routing, Reliability, ReliableMessaging, SecureConversation, Security, Transactions, Trust, and a frighteningly long list of other terms. Surveying this landscape, XML co-creator Tim Bray pronounced the WS-* stack “bloated, opaque, and insanely complex.”

It wasn’t always so. Simple forms of XML messaging were succeeding in the field long before any of these standards emerged. At InfoWorld’s SOA Executive Forum in May, Metratech CTO Jim Culbert described how his company’s service-oriented billing system worked back in the late 1990s. The messages exchanged among partners were modeled in XML and transported using HTTP with SSL encryption -- the method still used for most secure Web services communication today. Seybold analyst Brenda Michelson, who was then chief architect at L.L. Bean, tells a similar story about that company’s early experience with Web services.

Two factors were prominent at the time. First, the Web offered a simple, pervasive integration framework, one later promoted to the status of architecture and assigned the label REST (Representational State Transfer). Second, XML provided a universal way to define services in terms of the data they produced or consumed, rather than in terms of the code that produced or consumed the data. In combination, these factors were -- and still are -- powerful enablers.

Cranking Up Complexity
How, then, did we arrive at WS-*, which Culbert and others say is a cart that's gotten way ahead of its horse? One theory holds that the heavy-hitting vendors, working closely with key customers and partners, have ratcheted complexity up to a level that only they will be able to sustain. Because those specs are so far ahead of what most users need today, their development hasn’t been an organic process driven by well-known requirements.

Patrick Gannon, president and CEO of OASIS, the standards body now coordinating a number of the WS-* specifications, reluctantly agrees that users should have been more engaged from the beginning. “I wasn’t involved in creating those specs without formal user requirements on the table,” he says. “But I’m a pragmatist; the specs are there.”

Another view holds that industry heavyweights, who have paid their dues when it comes to security, transactions, and reliable messaging, are indeed qualified to translate their experience in these matters into the language of XML. TN Subramaniam, director of technology at RouteOne, which makes software that streamlines credit management applications on behalf of car dealers, learned that lesson the hard way. At one point he began drafting his own spec for single sign-on, only to abandon it when he discovered SAML, which his joint-venture partners enthusiastically adopted because all their identity management vendors -- including Netegrity and Oblix -- were supporting it.