W3C home > Mailing lists > Public > public-ws-chor@w3.org > July 2003

Re: Simple Choreography composition suggestion

From: Andrew Berry <andyb@whyanbeel.net>
Date: Thu, 17 Jul 2003 00:22:24 +1000
Cc: public-ws-chor@w3.org
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Message-Id: <EBB595FB-B798-11D7-9009-0003936786BC@whyanbeel.net>

On Wednesday, July 16, 2003, at 11:57  PM, Champion, Mike wrote:

>> -----Original Message-----
>> From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
>> Sent: Wednesday, July 16, 2003 9:12 AM
>> To: public-ws-chor@w3.org
>> Subject: FW: Simple Choreography composition suggestion
>> The point I disagree with is the notion that something is not a
>> Choreography if somewhere, at some level it involves 'orchestration'
>> within a single system.  If we accept this notion /
>> restriction it means
>> that you can only have Choreographies involving exactly two parties
>> where each party only plays a single role - we will not be
>> able to have
>> Choreographies with more than two parties / roles at all.
> That wasn't my intent, FWIW.  All sorts of compositions and 
> decompositions
> can occur within a "choreography," but IMHO only those that involve the
> globally visible shared state are in scope for the choreography 
> description
> language we are developing.

I'd urge caution whenever you use the terms "global" and "state" in the 
same phrase.  If you're talking about modelling then it's probably OK, 
but run-time state shared between participants connected via the 
Internet is a recipe for software that will never perform or scale.  
Consider for example that Sun recommends not using Jini outside a LAN 
environment because the synchronisation requirements of the tuple space 
(shared state) kill performance and reliability.

There are co-ordination approaches that can operate on a local, partial 
view of the process state.  HP have done this in their labs with some 
of their workflow tools.  My PhD thesis provides another solution.


Received on Wednesday, 16 July 2003 10:20:43 UTC

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