In the e-commerce business dance floor, the new digital jumps and jives demand real-time connections to many business steps and swings. No longer is it satisfactory to just shuffle data to update a single process overnight in batch. For example, a consumer enters a website to buy a new PC. The transaction must interact with the vendor CRM system, the vendor inventory (ERP) system, and a payment clearing service (authorize.net). The challenge is that all of the required left footed touchpoints are not necessarily listening to the same music. In order solve this tangled mess, web developers must teach their webs to tango.
In the past, these web dance steps were strictly defined and tightly coupled. The digital participants simply stepped into painted shoe prints on the cyber floor. This enabled high efficiency, but changes were difficult and expansion opportunities limited. If any system were changed, then all had to be upgraded or retested as the changes could have a wide impact. If the vendor needed to expand, it was difficult to engage other products from other vendors with system not under the local control. Our webs were being pushed to do more than 2-step, but the costs were too high to learn the more exotic dances.
The first solution was to establish “orchestration”. This is essentially a local and centrally defined model as to how the interaction will behave. Certainly, a conductor could enforce the right moves, right? The developers essentially enforced a certain structure for inputs, outputs, and error handling. This evolved into WS-BPEL (Business Process Execution Language) which can be defined as (3):
· It is a web service with runtime semantics and central control
· Abstract definition of end point protocols
· Executes the specified WSDL (Web Service Descriptive Message) message calls
· Encourages reuse of WSDL resources
But this still didn’t create the beautiful ballet we needed. The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are tightly controlled. In other words, orchestration refers to the central control of a distributed system while choreography refers to a distributed system which operates according to choreography rules but without centralized control. (1) The challenges to the old orchestration WS-BPEL dance are:
· It requires centralized execution
· The semantics are not globally formalized
· It is not scalable as dual control and connectivity are required
· It is rigid so it is non-collaborative
Originally marketed by Oracle, Web Services Choreography Descriptive Language is a specification by the W3C defining a XML-based business process modeling language that describes collaboration protocols of cooperating peer Web Services. The XML model defines a global scenario which is long-lived and stateful without a single point of control. Each service executes its own orchestration based upon its defined role and sequence. (2) The W3C Web Services Choreography Working Group, was closed on the 10th July 2009 leaving WS-CDL as a Candidate Recommendation which is intended to (3):
· Promote a common understanding between services
· Automatically guarantee conformance which reduces cost of ownership
· Ensure interoperability through behavior contracts
· Increase robustness and utilization
· Generate code skeletons
The key components of WS-CDL are:
· interactions
· Channels
· Participants
· Roles
· State
WS-CDL fits on top of the new technology stack as the key glue to bring it all together and make it work in the global context (4).
The design approach is different:
· BPEL: Design the baby steps first then put them together into a waltz.
· WS-CDL: Establish the flow of the tango first then distill it into simpler moves. (From WS-CDL we can generate BPEL/Java/C# logic for each participant.)
This gives very different results (4):
- BPEL: Participant specific viewpoints of control-flow (sequence, flow, switch, control links, exception handlers) based on the rigid imperative model
- WS-CDL: Global reactive rules for declaratively prescribing normal/abnormal progress, based on the flexible information driven model
The components of WS-CDL are:
- Typing. This defines the information types and location.
- Identifying & Coupling Collaborating Participants. In other words, the XML defines the participants, their roles, and how they relate together so there is no overlap or competition causing race conditions or deadlocks.
- Information Driven Collaborations. The key elements are the channel type, variable definitions, activities, and units of work. For example:
<variableDefinitions> <variable name=”ncname” InformationType=”qname”|channelType=”qname” Mutable=”true|false”? Free=”true|false”? Silent-action=”true|false”? role=”qname”? />+</variableDefinitions>
- Activities. These are interactions which enable collaborating participants to communicate and align information
The end purpose of Choreography is to combine actions with common behavioral characteristics, building a unit of work. In order to list all the binary relationships the dance is often expressed in complex PI calculus notations. The notation shows alternative patterns of behavior using workunits. This enables recovery backward by using exception handling and forward by finalizing already completed activities. But it has some drawbacks (5):
• Lack of separation between meta-model and syntax. The WS-CDL specification tries tosimultaneously define a meta-model for service choreography and an XML syntax.
• Lack of direct support for certain categories of use cases. Currently, WS-CDL does not support use cases with one-to-many or multi-transmission interactions.
• Lack of comprehensive formal grounding. While WS-CDL borrows some terminology from pi calculus, there is no comprehensive mapping from WS-CDL to pi-calculus or any other formalism.
The bottom line is that Choreography complements Orchestration. Choreography is concerned with global, multi-party, peer-to-peer collaborations, between application components, distributed within or across an organizations trusted domain (5). WS-CDL can allow a developer to get their web into the global ball. However, its complex notation and broad scope may be too overwhelming for so many dancers that they just sit this one out and head for the bar.
References
(1) Business Process Execution Language. http://en.wikipedia.org/wiki/WS-BPEL
(2) Web Service Choreography. http://en.wikipedia.org/wiki/Web_Service_Choreography
(3) Web Services Choreography and Process Algebra. 29 April 2004. Steve Ross Talbot http://www.authorstream.com/Presentation/Junyo-29185-WS-CDL-Web-Services-ChoreographyandProce-ss-Algebra-Agenda-Orchestration-vs-Choreography-BPEL-as-Entertainment-ppt-powerpoint/
(4) Aggregating Web Services: Choreography and WS-CDL. Nickolaos Kavantzas, Oracle. http://www.fpml.org/_wgmail/_bpwgmail/pdf0BHcCh7tU4.pdf
(5) A Critical Overview of the Web Services Choreography Description Language. Alistair Barros. March 2005. http://search.yahoo.com/r/_ylt=A0oG7mbDOKZNOFcAzDxXNyoA;_ylu=X3oDMTEyY21kaGljBHNlYwNzcgRwb3MDMQRjb2xvA2FjMgR2dGlkA0RGUjVfODc-/SIG=14r8m9pbf/EXP=1302760739/**http%3a//bptrends.com/deliver_file.cfm%3ffileType=publication%26fileName=03%252D05%2520
WP%2520WS%252DCDL%2520Barros%2520et%2520al%252Epdf
(6) Web Services Choreography Description Language Version 1.0. W3C Candidate Recommendation 9 November 2005. http://www.w3.org/TR/ws-cdl-10/
(7) WS-Choreography Definition Language (WS-CDL) . EBPML working group. http://www.ebpml.org/ws_-_cdl.htm
(8) http://lists.w3.org/Archives/Public/public-ws-chor/2004Jun/0024.html
Trent Richardson's Blog 