John Reynolds's Blog

Service Orchestration vs. Service Choreography

Do you know the difference between Web Service Orchestration and Web Service Choreography?

The distinction between WS-Orchestration and WS-Choreography is important to understand, but unfortunately the vocabulary that we are defining for dealing with web services and SOA is... uh... (How shall I put it?)... unhelpful.

One definition that I found for "orchestration" on the web is the following:

"Orchestration or arrangement is the study and practice of arranging music for an orchestra or musical ensemble. In practical terms it consists of deciding which instruments should play which notes in a piece of music."

A similar search for the definition of "choreography" returned the following:

Choreography is: "the arrangement and movement of performers onstage; though the term cutomarily applies to dancers, it is also used to denote the orchestrated movement of actors, especially in stage combat"

Based on these definitions, Orchestration is about music and Choreograhy is about dance... but for some odd reason this doesn't help me grok the distinction between WS-Orchestration and WS-Choreography.

The real distinction lies not in the dictionary, but in the differences between the Business Process Execution Language (WS-BPEL) and the Web Services Choreography Description Language (WS-CDL).

Orchestration == Executeable Process

Web Service Orchestration relates to the execution of specific business processes. WS-BPEL is a language for defining processes that can be executed on an orchestration engine.

Choreography == Multi-party Collaboration

Web Service Choreography relates to describing externally observable interactions between web services. WS-CDL is a language for describing multi-party contracts and is somewhat like an extension of WSDL: WSDL describes web services interfaces, WS-CDL describes collaborations between web services.

Ah, if only the "C" in WS-CDL was for "Collaboration" instead of for "Choreography"... life may have been a little simpler ;-)

Comments

• From my perspective the WS-* specifications are DOA. And SOAP only lives on as a part of the ebXML messaging service. Above that, it is all REST. But I probably don't see the whole picture...

  Posted by: tobega on January 19, 2006 at 03:56 PM

• To confuse two such clearly obvious terms indicates:

  You have significant lackage in your bizspeak potentiality maximisation. The thoughtful selectage of these terms was intrinsically to synergise the collective diversity of their substantial commonality.

  :-)

  Posted by: cajo on January 20, 2006 at 05:22 AM

• Cajo,Me no speak good, but me look good ;-)

  
  Tobega,I'm not so sure that WS-* specs are dead on arrival, but they certainly have been an interesting case study in the powers of natural selection. The number of "extinct" specifications is somewhat amazing given the relative infancy of Web Service Oriented Programming (WSOP), but it's also understandable given the lack of a clear "owner" for all things WSOP.

  -- JohnR

  Posted by: johnreynolds on January 20, 2006 at 06:28 AM

• Mark Hapner's recent article on SOA has some great advice regarding standards:
  "Creating web sites showed us what could be done with very minimal standards. Rather than waiting for any one vendor's highly complex architecture, I'd suggest starting with the minimal functionality that's needed, and as applications mature, be conservative in introducing new infrastructure and protocols."

  "Go ahead and use the technologies in small projects and learn what you need to get interoperability. The real issue is not the protocols but rather the application-level value they enable. Most web developers don't obsess about the details of HTTP -- they just use it to deliver the function of their web site. "
  

  Posted by: johnreynolds on January 20, 2006 at 07:27 AM

• How do you Choreograph internal Services? It is a internal usage of WS-CDL still Choerography?

  What is the usage of abstract BPEL supposed to be?

  What is a BPEL Engine with a import for WS-CDL?

  I dont see it is helpfull to be so strict on those terms since modern Software integrates all of those aspects.

  Bernd

  Posted by: ecki on January 22, 2006 at 09:49 AM

• I agree with you ecki, most projects are going to incorporate both orchestration and choreography aspects, but I do see some value in decoupling those aspects when it makes sense to do so.

  WS-CDL is primarily for the case where multiple parties (business partners) don't want to expose their actual business processes to each other... it can be used internally, but it's less justifiable and may not be worth the trouble.

  BPEL would import WS-CDL when your internal process is very dependent on external services that are not entirely stateless (order matters). You could (of course) forgo WS-CDL if you knew the terms of your contract with the external parties, but that's precisely what WS-CDL is telling you. Once again, it's a value call you will have to make.
  --JohnR

  Posted by: johnreynolds on January 23, 2006 at 03:32 PM

• As I understand it, Choreography is the total process involving multiple WSDLs (different services/companies) and Orchestration is the total process within a single WSDL which may implement the service in a number of different ways. It's easier to see on a bus-type architecture.

  Posted by: wpbarr on January 24, 2006 at 10:14 AM

• Many years ago, E. Dijkstra warned all of us against the use of human metaphors in Computer Science. I see here a confirmation of his warning.

  Although I'm not an expert in the field, I see that many people in it are using a really wrong approach. They name something without really understand it. And then, to understand it, they look for the human definition of the word they have chosen. This only leads to more confusion.

  Posted by: domingogallardo on January 25, 2006 at 04:10 AM

• 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

  Posted by: steverosstalbot on January 25, 2006 at 05:40 AM

• Thanks Steve,I grok your distinction between the conductor of a symphony and a choreographer who plays no part once the dance has begun.
  I get a bit confused when you say:"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? "
  What entity would be doing the monitoring?
  With orchestration, you have the conductor (the orchestration engine). With choreography, what is checking up on the services to assure that they are performing as desired? Does each "dancer" check up on their own partners?

  --JohnR

  Posted by: johnreynolds on January 25, 2006 at 05:58 AM

• 
  The monitoring, at least inside a firewall so within an enterprise, would be based on a similar state machine per service. Think of it as a sniffer that observes messages in and out of a service that understands what should be happening based on the projection from the WS-CDL description.

  
  Then imagine such a monitor (the state machine monitor) sending out messages (perhaps publishing them on JMS) about what is going on (the observations). Then imagine a consumer of these messages from all of the services that are being monitored that simply correlates the individual behavior observations back to the original WS-CDL description. This could then provide a view onto the execution of the system as whole against the plan described in the WS-CDL description.

  
  Have a look at: http://lists.w3.org/Archives/Public/www-archive/2006Jan/att-0028/Imperial.ppt and the slide on the Behavioral Monitor

  
  Does that answer your question?

  
  Steve T

  Posted by: steverosstalbot on January 25, 2006 at 06:15 AM

• Great answer Steve.You're my hero ;-)--JohnR

  Posted by: johnreynolds on January 25, 2006 at 11:35 AM

This work is licensed under a Creative Commons License.