- From: Andrew Berry <andyb@whyanbeel.net>
- Date: Thu, 17 Jul 2003 00:22:24 +1000
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Cc: public-ws-chor@w3.org
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. Ciao, AndyB
Received on Wednesday, 16 July 2003 10:20:43 UTC