Web services’ human touch

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.