W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Definition of Choreography

From: Ricky Ho <riho@cisco.com>
Date: Sun, 20 Oct 2002 08:46:21 -0700
Message-Id: <4.3.2.7.2.20021020082240.048754f8@franklin.cisco.com>
To: "Mathews, Walden" <walden.mathews@tfn.com>, "Mathews, Walden" <walden.mathews@tfn.com>, "''Champion, Mike ' '" <Mike.Champion@SoftwareAG-USA.com>, "''www-ws-arch@w3.org ' '" <www-ws-arch@w3.org>

Hi Mathew, my response as embedded ...

> >Hi Mathew,
>
> >I don't think the guard condition is a good idea because it expose the
> >private implementation about how its decision being made.  If you want
> >to model the situation that it is possible to state with the current
> >state when some event occur, you just need to add the current state as
> >the possible next state after the event occur.
>
>I don't agree that guard conditions are private.  They're part of the
>interface, every bit as public (logically) as the states themselves.  In
>fact, they are just sub-states organized that way for brevity and clarity.

Lets model a ordering process.  Buyer send a purchase order to the seller 
("start" state), and the seller may accept it ("accepted" state) or reject 
it ("rejected" state) based on whether the stock has enough units.  Another 
seller may be based on whether the buyer has a good credit.  Can you show 
me how do I use your XML language to describe the model without exposing 
how the seller may make his decision ?  In my language, it will be done as

<choreography>
     <state name="startState">
         <transition>
             <event name="receiveOrder" nextState="acceptedState 
rejectedState"/>
         </transition>
     </state>
     </state name="acceptedState"/>
     <state name="rejectedState"/>
</state>

> >In your model, when trigger X occurs, it always move to a particular
> >next state.  Such representation also unnecessary expose the private
> >decision about how the processing of an event is related to the next
> >state.  It will be better to allow multiple possible next state within a
> >trigger.
>
>Again, there's nothing "private" being exposed.  The "trigger/guard"
>facet is necessary to model machines in which there are multiple distinct
>arcs from one state to another.

In your model representation, it is NOT possible to describe the situation 
that one event occurance can lead to multiple possible next states without 
using the guard conditions.  And using guard condition has two risks.
1) It force the implementor to publicize its decision making criteria. (we 
may disagree on whether guard condition is private or public, but your 
answer to my above example will make it clear)
2) There is no way to enforce guard conditions to be mutually 
exclusive.  (what is the next state if two different guard conditions 
leading to them are both true ?)


> >Following is an example I try to put up.  My "event" is probably same as
> >your "trigger", and I further constraint the event can only be a web
> >service message exchange.
>
>If I'm in state1 (balanced on a rock amid a rushing torrent) and I want
>to get to state 3 (safe on the opposite bank) and avoid state 2 (drowned),
>how would I use your model safely?

Very easy, you just don't specify state2 in the attribute "nextState" of 
eventX.

<state name="state1">
     <transition>
         <event name="eventX" nextState="state3"/>
     </transition>
     <transition> .... </transition>
</state>

Rgds, Ricky
Received on Sunday, 20 October 2002 11:47:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT