W3C home > Mailing lists > Public > public-ws-chor@w3.org > January 2004

RE: Choreography and Orchestration

From: Jean-Jacques Dubray <jeanjadu@Attachmate.com>
Date: Thu, 29 Jan 2004 18:05:59 -0800
Message-ID: <D15269CBED76D51185280008C73323FA029B25E9@exch-bel6.attachmate.com>
To: "Monika Solanki" <monika@dmu.ac.uk>, "Steve Ross-Talbot" <steve@enigmatec.net>
Cc: <public-ws-chor@w3.org>

Monika:

Note that all are a form of coordination. WS-CAF presents a very
abstract framework from which you can build all forms of coordinations:
Composition
Orchestration
Transaction
Choreography
Collaboration
...

WS-CAF suggests that to build a "coordinator" (not an orchestrator), you
need as least a context manager and activity lifecycle manager. 

Interestingly enough a binary collaboration or choreography is
self-coordinated (or more accurately as Bob Haugen puts it: the
coordination responsibility is shared between parties). 

I sense that we are close to a unified coordination model...

This is not on ebpml.org but coming soon ;-)

JJ-

-----Original Message-----
From: Monika Solanki [mailto:monika@dmu.ac.uk] 
Sent: Thursday, January 29, 2004 10:48 AM
To: Steve Ross-Talbot
Cc: public-ws-chor@w3.org
Subject: Re: Choreography and Orchestration


Thanks Steve. This has indeed helped.

-Monika

Steve Ross-Talbot wrote:

>
> Monika,
>
> The simple answer is that orchestration implies a centralised control 
> mechanism (i.e. the conductor in an orchestra), whereas choreography 
> does not (dancers on a stage). In the former the players have a score 
> that they adhere to (in BPEL this might be the abstract BPEL defs for 
> the individual components) and the conductor ensures they all work 
> togther harmoniously (the rest of BPEL). In the latter all the dancers

> have a choreography and understand their role in the overall dance 
> because it has been agreed or imposed for them.
>
> Orchestration is typically used in a domain of control. Choreography 
> would be used across domain of control to ensure harmony 
> (interoperability etc).
>
> Choreography is sometimes viewed as a peer2peer global model of the 
> external observable behaviour of the interacting components. We can 
> think of this as a global behavioural contract that might be used to 
> generate component stubs (i.e. Skeletal code) and/or with a tool by 
> one or more components that is used to monitor the contract or even 
> statically as input to a tool to reason about the behaviour (are there

> any deadlock or livelocks in this contract?).
>
> Hope this helps.
>
> Steve T
>
> On 28 Jan 2004, at 19:07, Monika Solanki wrote:
>
>>
>> There has been extensive discussions  on the conceptual differences 
>> between the above two terms. I was interested in documents that 
>> formally capture them. If  such documents exists, it would be great 
>> if someone can forward pointers to them.
>>
>> Thanks,
>>
>> Monika
>> p.s; I have already explored www.ebpml.org
>> -- 
>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>> Monika Solanki
>> Software Technology Research Laboratory(STRL)
>> De Montfort University
>> Hawthorn building, H00.18
>> The Gateway
>> Leicester LE1 9BH, UK
>>
>> phone: +44 (0)116 250 6170 intern: 6170
>> email: monika@dmu.ac.uk
>> web: http://www.cse.dmu.ac.uk/~monika
>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>>
>> This email is confidential and may be protected by legal privilege. 
>> If you are not the intended recipient,  please do not copy or 
>> disclose its content but  delete the email and contact the sender 
>> immediately. Whilst we run antivirus software on all internet emails 
>> we are not liable for any loss or damage. The recipient is advised to

>> run their own antivirus software.
>>
>
> This email is confidential and may be protected by legal privilege. If

> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> Whilst we run antivirus software on all internet emails we are not 
> liable for any loss or damage. The recipient is advised to run their 
> own antivirus software.
>

-- 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
Monika Solanki
Software Technology Research Laboratory(STRL)
De Montfort University
Hawthorn building, H00.18
The Gateway
Leicester LE1 9BH, UK

phone: +44 (0)116 250 6170 intern: 6170
email: monika@dmu.ac.uk
web: http://www.cse.dmu.ac.uk/~monika
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
Received on Thursday, 29 January 2004 21:08:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:03 UTC