- From: Monika Solanki <monika@dmu.ac.uk>
- Date: Thu, 29 Jan 2004 18:48:07 +0000
- To: Steve Ross-Talbot <steve@enigmatec.net>
- Cc: public-ws-chor@w3.org
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 20:47:49 UTC