Orchestrate services
Three proposals describe how Web services can model and combine business processes
FOR YEARS THE INDUSTRY has dreamed of modeling business processes in software and combining them like Tinker Toys. Web services orchestration, the new term for that old idea, becomes more interesting as raw services multiply behind firewalls. But as integration vendors point out, the orchestration layers of the Web services stack aren’t yet baked. The standards pioneers — Microsoft, IBM, and now Sun Microsystems and BEA Systems — are busy in the kitchen.
Two proposed XML grammars for describing the orchestration of Web services — Microsoft’s XLANG, used by BizTalk, and IBM’s WSFL (Web Services Flow Language) — were widely expected to have merged by now into a joint World Wide Web Consortium (W3C) submission. That hasn’t happened. Meanwhile, Sun, BEA, SAP, and Intalio have introduced a third candidate: WSCI (Web Service Choreography Interface). The relationships among these three proposals — and others, including Intalio’s BPML (Business Process Markup Language) and ebXML’s BPSS (Business Process Schema Specification) — are murky.
XLANG, WSFL, and WSCI talk about two different orchestration layers. One layer deals with the public protocols of business collaboration, which WSFL and WSCI call the global model. The other layer describes private protocols, which WSFL calls the flow model. XLANG addresses both layers, but less explicitly. Ideally, a W3C recommendation will emerge that splits these apart neatly, but it’s not yet clear how to do that.
All three XML grammars define standard programming language constructs for sequences, loops, spawning, conditional execution, and exception handling. XLANG and WSCI have roots in a formal algebra called pi-calculus, which is used to model the kinds of parallel, message-driven computations that make orchestration a uniquely difficult problem.
XML is a lousy syntax for programming languages, and BizTalk developers have longed for something more programmer-friendly. For XLANG users, help is on the way, according to Dave Wascha, lead product manager for BizTalk at Redmond, Wash.-based Microsoft. XML should be used to specify service choreography, he says, but it need not be used to implement it. A conventional syntax can do this more naturally, as Microsoft has shown in experiments using C#.
In a similar vein, Java implements the conversational Web services defined in BEA’s WebLogic Workshop, and Collaxa’s ScenarioBeans mixes workflow tags with Java, creating a JSP (JavaServer Pages)-like metaphor that aims to be intuitive for developers.
Shared public protocols, however, must be language-neutral, which mandates XML. At this level, all three proposals explore grammars that describe dynamic interplay among services offering static WSDL (Web Services Description Language) interfaces. With respect to loosely coupled, asynchronous services, this is where rubber meets road. Problems that far-flung service orchestration forces us to confront include message correlation, long-running transactions, and human-usable abstractions.
Message correlation
BEA’s WebLogic Workshop makes pairwise conversations transparently simple. A developer declares a service “conversational,” and an ID is attached to subsequent message flow. By doing a little surgery on its SOAP (Simple Object Access Protocol) headers, a .Net client can join a WebLogic-style conversation. But orchestration, in the general case, is a many-to-many conversation — and one in which not every participant will necessarily even speak SOAP.
“Are we going to standardize on a specific place in a message that has a conversation ID?” asks David Orchard, a technical director at BEA in San Jose, Calif. “Or do we define correlation at the interface level?” The latter approach would include EDI, RosettaNet, or other kinds of participants.
Even when everybody does speak SOAP, the nature of the message fabric is unclear. SOAP routing seems a likely substrate, but Bob Sutor, director of e-business standards strategy at IBM in Armonk, N.Y., doesn’t see this as a necessary building block. “You’d think SOAP routing would be fundamental,” he says, “but we’ve survived without it.”
Long-running transactions
Delayed approval of a purchase order is one of the classic motivations for loose coupling. There’s plumbing now in BizTalk to support this scenario.
When the order process is interrupted, it’s not enough just to roll back the effects of activities that are under way. Business protocols typically specify compensation — for example, penalties and fees. Such compensation must therefore be modeled explicitly as part of the global model. XLANG and WSCI include syntax for doing this.
The example illustrated in the XLANG, WSFL, and WSCI specs is an airline ticketing scenario involving a traveler, an agent, and an airline. XML can represent this scenario in a way that enables diverse software systems to collaborate. But no human reader (or writer) of these documents can hope to understand the dynamic behavior in terms of the XML. Diagrams aren’t simply eye candy here — they’re essential.
It’s likely that a standard diagramming system, perhaps based on UML (Universal Modeling Language), will play an important role in orchestration. But as Redwood Shores, Calif.-based Collaxa’s CEO Edwin Khodabakchian points out, the complexity of business processes in the real world quickly overwhelms what graphs can represent.
“We need more use cases,” Khodabakchian says. Microsoft’s Wascha, IBM’s Sutor, and BEA’s Orchard all agree. No one thinks any one of the current specs is a final road map. It’s going to take a lot more practicing before this orchestra can really play.
