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.
"What are the chances,” Subramaniam asks, “that five architects meeting every other day will iron out all the possibilities,
versus having a committee thinking it all through in great detail with all the vendors on board?"
It’s tempting to interpret the tension between these two perspectives as a replay of the cathedral and the bazaar — or perhaps
instead, WS-Heavy and WS-Lite. In that dichotomy, WS-Heavy would refer to the security, reliability, and scalability that
WS-* claims to deliver, whereas WS-Lite would mean the speed, simplicity, and agility that attract labels such as REST, AJAX,
and RSS. None of the enterprise architects we interviewed for this story has pledged allegiance to either of these camps,
though. They’re intensely pragmatic people who will do whatever it takes to get the job done, and it’s instructive to learn
how they are -- and are not -- making use of Web services standards.
RouteOne: Securing Credit Checks
Although end-to-end SSL is often sufficient, RouteOne’s Subramaniam has two reasons to prefer the more granular approach enabled
by WS-Security. First, it’s necessary to digitally sign the credit applications his application transmits, and to do so according
to rules understood by service partners. WS-Security defines such rules, although admittedly, and unfortunately, too many
of them. One method is to put the signed application into the body of the SOAP message; another is to use SOAP with attachments.
In the end, there was no agreement among the service partners, so RouteOne uses both. That’s frustrating, but Subramamian
would rather have two rules than none.
The second reason touches on one of the deep principles that motivates the design of the WS-* stack: pervasive intermediation.
RouteOne is required to maintain meticulous audit logs and would prefer not to have to encrypt all of them. So it’s using
DataPower’s XML router/accelerator to selectively encrypt only sensitive items such as gross pay and Social Security number.
Because it’s a standards-based intermediary, the DataPower box can straightforwardly modify RouteOne’s XML message traffic
in this way, and it could be swapped out for another appliance that did the same thing.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
