The notion of a Web services "revolution" provokes and deserves skepticism. Web services bring no new technologies to the
table. Rather, they promise to recombine familiar things to achieve a greatly-desired effect: closer alignment of IT infrastructure
with business processes. XML syntax is the catalyst, but XML documents -- onscreen, on the wire, in the database -- are the
tangible stuff of a new synthesis.
Why aren't Web services just client/server or CORBA or DCOM done with angle brackets? Because none of those distributed-computing
technologies made room for the messy human context that surrounds every business transaction. The secret sauce of Web services
isn't XML per se, it's convergence on the XML document (aka message payload, aka database record) as a shared representation
of the business transaction.
Purchase orders, bills, insurance claims, and other business protocols tend to inhabit parallel universes. In the IT realm,
they're transactions that can exist in a finite number of states (active, aborted, and so on); undergo orderly transition
among those states; and commit well-defined bundles of structured data to operational databases. In the business world, they're
transactions that involve actors with agendas, are subject to negotiation, and accrete contextual information that's rarely
managed.
As Web services standards climb the ladder of abstraction, from raw XML message formats to "conversational" message exchange
patterns to process "choreography" and "orchestration," the language grows ever more evocative. In BPEL4WS (Business Process
Execution Language for Web Services) and related specifications, "compensation" is a key term. "While a business process is
running," an IBM white paper on BPEL4WS dryly notes, "it might be necessary to undo one of the steps that have already been
successfully completed."
Translation: Things can get screwed up, and then they need to be fixed. If there's anything revolutionary about Web services,
it's the notion that we'll be able to deal with the inevitable screwups in more realistic and more effective ways. Compensation
can't simply mean what it does to a programmer: chaining back through a nested series of automatic exception handlers. We
have to accept that it's often people who both throw and handle the exceptions, and we have to build software systems that
gracefully include them.
With its support for XML documents, Office 2003 starts to bring end-user software into the loop. The road map for Longhorn,
Microsoft's next-generation client OS, spells out a related goal. John Shewchuk, one of the architects of Longhorn's Indigo
communication subsystem, says that its messaging engine will be based on Web services standards but will be optimized for
efficient use by local applications that today converse using proprietary protocols. He draws an analogy to local- and wide-area
networking. "We learned that you could take a protocol built to work in-the-large, namely TCP," says Shewchuk, "and make it
perform as well [within a small delta] as a local system."
Consolidation around TCP broadened the scope of basic network programming. Now Microsoft hopes that Indigo's proposed consolidation
of transports (TCP, HTTP), topologies (client/server, peer-to-peer), and message-exchange patterns (request/response, publish/subscribe)
will broaden the scope of Web services. The details remain sketchy, but the plan is sound. A claims adjustment process and
a claims adjuster can interact with the same XML document. By the same token, the messages bearing that document can travel
as freely among desktop applications as they do in the services cloud. That new level of IT/business alignment neatly summarizes
the Web services difference.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
