Pointer to article:
Orchestration standards continue to proliferate like orchids in a hothouse.
I use the term “orchestration” as the catch-all for this entire space of standards. I’ve personally standardized on “orchestration” as the master term, rather than any of the many synonyms, such as choreography, workflow, and business process management (BPM). I’m just tired of the industry proliferating unnecessary, confusing synonyms for the same phenomenon. And they all do refer to the same core phenomenon: the rule-driven flow of content, context, and control throughout a distributed business process. This core definition is agnostic to such concerns as where the rules engines reside in this orchestrated process (intermediaries or endpoints or mix of both), what the endpoints of this process might be (applications, humans, devices, or what have you), and so forth.
It’s important to note that WS-CDL and WS-BPEL are complementary orchestration standards. WS-CDL would be used to define orchestration rules executed by process endpoints (vis-à-vis the orchestrated message exchange patterns in which those endpoints participate). WS-BPEL, by contrast, is used to define orchestration rules executed by process intermediaries (e.g., integration brokers), vis-à-vis the orchestrated message exchange patterns in which those intermediaries participate.
WS-CDL 1.0 addresses a narrower functional scope than its defunct W3C predecessor, WSCI 1.0, which attempted to match WS-BPEL as a full-fledged orchestration execution language that drives processing at intermediary nodes known as “integration brokers” or “orchestration engines.” WS-CDL 1.0 only addresses the observable, structured interactions of Web services with their users, which may include humans, applications, and/or other Web services. WS-CDL 1.0 can describe peer-to-peer, cross-enterprise, message exchange patterns associated with interactions among users, applications, and/or Web services endpoints. It supports both WSDL 2.0 and SOAP 1.2.
WS-CDL 1.0 documents are essentially “contracts” that govern orchestrated interactions among two or more endpoints. WS-CDL documents are exchanged between endpoints through various means. These documents provide endpoints with the information necessary to mutually establish, coordinate, and manage orchestrated interactions, which may involve peer-to-peer message exchanges or be routed through intermediaries such as integration brokers. Essentially, WS-CDL may be used to describe the coordination context as viewed by distributed participants in orchestrated business processes.
A WS-CDL document defines participants, roles, relationships, interaction patterns (including specification of messages, channels, ordering, constraints), and interaction lifecycle associated with two or more endpoints in a distributed business process. WS-CDL interaction lifecycles specify conditions under which endpoints instantiate, transition, and complete all the steps in a business process, as well as what messages are to be sent and/or received within each of those lifecycle stages. Lifecycle specifications also describe the message exchanges under which endpoints handle errors and recover from aborted or failed business processes.
As I said, WS-CDL 1.0 is complementary to WS-BPEL. Conceivably, a WS-CDL 1.0 contract can be used to determine whether an orchestration developed and executed in WS-BPEL exhibits the message exchange patterns expected by various endpoints in a business process. WS-CDL 1.0 contracts would describe the message sequence and conditions expected by each participating endpoint node, whereas a WS-BPEL orchestration would specify precisely how an orchestration engine executes each step in a complex, multipoint business process. However, W3C and OASIS are not coordinating their work on the respective specifications, and WS-BPEL’s primary advocates—Microsoft and IBM—are not participating in W3C’s development of WS-CDL.
So the orchestration standards wars continue. There’s much more going on in this space than I care to elaborate on in this blog entry. I could write a book about it (actually, I’ve written two books on orchestration topics—not eager to write a third until the market actually starts demanding such titles).