Choreography standards do not spring up overnight. Indeed, the first crude set of choreographic symbols took more than 400 years and dozens of abandoned efforts to evolve into Hungarian dance master Rudolf von Laban's widely accepted notation for representing the ordered and complex movements of dance.
The developers working on Web services choreography standards expect to take less time than the dance master of yore, but the difficulty of the task at hand is much the same. They have to finesse technology nuances and please a variety of constituencies. At issue is how to define a standard way of letting business processes talk to each other during the course of a Web services transaction. Standardization would make Web services easier to develop -- and deploy.
With Web services now, if a company wants to share parts of an application with a business partner, it can talk about the ports and operations it will expose using a Web Services Description Language (WSDL) file. The WSDL file would describe simple operations such as "get fare quote" or "book ticket." But the company has no standard way of talking about the business processes that govern all these operations. WSDL can't tell an application not to bother trying to book a ticket before it's received a fare quote -- at least not in any standardized way.
To learn the business logic behind partner applications, developers must create a workflow document to which they can code. With Web services choreography, workflow descriptions are standardized. Instead of reading and manually coding to workflow specifications, developers could use typical development tools to handle this work.
Choreography standards put you "way ahead of the game," says Yaron Goland, a technologist at BEA Systems. "You're no longer sitting there trying to figure out, Now if I call this particular interface, what the heck do I do next?' "BEA Systems is working to incorporate Web services choreography features into its WebLogic Workshop development tool, and its competitors -- IBM, Microsoft and Sun Microsystems, for example -- are doing the same with their wares.
And that's where the problems begin.
On the dance card
In late June, Sun, along with BEA, Intalio and a number of other supporters, submitted a draft Web choreography specification, called the Web Service Choreography Interface (WSCI), to the World Wide Web Consortium (W3C). One month later, BEA, IBM and Microsoft published an alternative, the Business Process Execution Language for Web Services (BPEL4WS). Now Sun, Microsoft and IBM are sparring over which specification will become the standard. On the outside are vendors such as BEA and Oracle that are urging a convergence of the two specifications.
Users also are interested in convergence because it would give them a greater range of tool choices and, more importantly, because the alternative could result in a nasty standards war. Choreography standards are becoming increasingly important as company and customer business processes get more intertwined, says Hao He, a software architect with Thomson Legal & Regulatory, a major law and tax information publisher.
Thomson interacts with dozens of government agencies and law firms each day, indexing and editing government regulations and producing books, CD-ROMs and online databases of government regulations. Currently, Thompson uses custom-developed software to manage order fulfillment and to share inventory information with branch offices and customers. As Web services orchestration servers become available, the company hopes to use standard software from a variety of vendors to manage these processes, he says.
"It definitely helps if we can automate as many processes as possible using a standard technology," says He, who is a member of the W3C's Web Services Architecture Working Group. "The W3C is trying to identify a middle ground between [WSCI and BPEL4WS]. This is challenging because those two specs are quite different."
Stylish differences
The main difference between WSCI and BPEL4WS is one of scope. WSCI is about Web services choreography, while BPEL4WS includes choreography and orchestration specifications. This means that while both technologies cover the flow of messages between applications at a high level, BPEL4WS also talks about specifics, such as where to store incoming messages or what specific container to use as the body of the message. "Choreography says, It's supposed to look like this.' Orchestration says, It has to look like this,'" says Joanne Friedman, a Meta Group vice president.
But the technical differences between the two standards are not insurmountable, BEA's Goland contends "WSCI doesn't have the same [orchestration] features, but they would be fairly easy to add," he says. "In the end, the features will all be the same."
The W3C appears to agree. It says it would like the chance to consider both specifications, and it is lobbying IBM and Microsoft to submit BPEL4WS to the W3C rather than to any other group, such as the Organization for the Advancement of Structured Information Standards. At the W3C, parties would hash out the issues in a formal Web Services Choreography Working Group.
While IBM and Microsoft haven't committed their work to a standards body yet, observers say a standards war is unlikely. They point to Sun's recent membership in the Web Services Interoperability Consortium, a group it previously shunned while IBM and Microsoft played central roles. Sun's participation could help thaw the frosty relations.
Do a slow dance
Absent a single Web services choreography standard, Web developers should chart a prudent course, Friedman says. They should be certain that Web services provide a value-add to their businesses, and they should take the long view of their goals. "Then they'll have a better perspective with which to look at these specs, because right now," she says, "developers reading specifications without business use cases or a business reason to use reference implementations are looking at things in a vacuum."