Orchestrate services

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.