Livin' the life...

"Let me try to clear up any confusion that may exist about WS-CDL and WS-BPEL.

Firstly WS-CDL can be used to describe the observable behavior ,as interactions (message exchanges or WSDL function invocations), across a number of services (more than one). It's purpose is to clearly define the interoperablity needed to realise a system composed of many services.

Secondly, WS-BPEL is primarily focussed on composing new services from existing services. It provides a common way of describing the internal behavior of how these services need to work together in order to realise another service. So it has a single service perspective. It cannot be used to describe a system of services as peers because it yields a new service.

An orchestra typically has a conductor. Orchestration also has the equivalent - the orchestration engine.

Choreography has a choreographer who writes down the rules of engagement for the dancers, gets them to learn it and then leaves the stage to allow the dance to occur based on the rules. Choreography of services is similar. You write down the rules and use it to ensure that the "touch" points are preserved. This is akin to the externally observable behavior. The way in which a dancer performs the steps may be said to be orchestrated - they have a brain that controls their motor functions.

So you can see that a system described in WS-CDL may be realised as a set of peered islands of orchestration, which, based on the rules of engagement, work together to yield a system.

WS-CDL can be used to generate the observable behavior through role projection of services into WS-BPEL or any orchestration language (i.e. Java or CSharp, or ....). The non-observable business logic that is inside a service may be implemented in any end point language as long as the state machines behavior is preserved.

WS-CDL can also be used in a monitoring context to determine if services are well behaved - are they performing the dance steps correctly relative to each other?

WS-CDL is certainly related to WSDL but it is optional (check out the role defns in the spec). WSDL is certainly not capable of expressing what WS-CDL does. Oddly enough Abstract BPEL, if it were properly supported (and there is debate about that and what constiututes support), would be a good way of describing the state machine behavior of a single service. Then generating the service descriptions would be even easier by going from WS-CDL to Asbtract BPEL.

I agree very much that the two can be used in conjunction. WS-CDL for the system description (the sort of language architects dream of) and WS-BPEL for composite service construction.

Cheers

Steve Ross-Talbot

co-Chair W3C Choreography Working Group

Chair W3C Web Services Activities

www.pi4tech.com

www.pi4soa.org " (Ref)

Other interesting links:

http://pi4tech.blogspot.com/2008/02/orchestration-and-choreography-ws-bpel.html

http://blog.whatfettle.com/2005/02/16/choreography-vs-orchestration/