April 13, 2011

EE615 Trent Richardson

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):

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.)

· 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:

· 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.

• Lack of direct support for certain categories of use cases.

• Lack of comprehensive formal grounding.

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.