RE: Definition of Choreography

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.

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.

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.

I don't think "exception" need to be defined different in the 
model.  Basically, you only need to define some "state" to for exception 
situation, the event that reach those states are SOAP faults.  The same 
model can be used to represent the exception situation and its handling 
already.

Comments are very welcome !


<choreography startState="state1">
     <roleDefinition>
         <role name="roleA">
             <portType name="PT-A"/>
         </role>
          <role name="roleB">
             <portType name="PT-B"/>
         </role>
         <role>....</role>
    </roleDefinition>
     <state name="state1">
         <transition>
             <event name="eventX" nextState="state2 state3">
                 <invoke>
                     <sender role="roleA"/>
                     <receiver role="roleB">
                         <portType name="PT-B">
                             <operation name="opM"/>
                         </portType>
                     <receiver>
                 </invoke>
             </event>
         </transition>
         <transition> .... </transition>
     </state>
     <state>...</state>
</choreography>

Best regards,
Ricky

At 07:14 PM 10/19/2002 -0400, Mathews, Walden wrote:

> >> -----Original Message-----
> >> From: Ricky Ho [mailto:riho@cisco.com]
> >> Sent: Friday, October 18, 2002 9:17 PM
> >> To: Burdett, David; 'Champion, Mike'; www-ws-arch@w3.org
> >> Subject: RE: Definition of Choreography
> >>
> >>
> >> Can the public protocol be just an XML
> >> representation of a state machine.  Each state constraint
> >> what event can  happen (event can be what SOAP message to send or what
>SOAP
> >> message to  receive).  Each event defines the next state.
>Effectively,
> >> we are defining  what are the possible message exchange sequence
>without
> >> describing the  internal decision making process.
>
> >I like this idea a lot.  Can anyone sketch out an example of how one
> >might
> >model a little corner of one of the choreography specs using a state
> >machine
> >notation?
>
>Here's a sketch of the essentials of state modeling using something
>that looks phenomenally like XML to represent the concept of a Harel
>statechart:
>
><machine>
>   <state name="X">
>     <next-state name="Y">
>       <transition>
>         <trigger>...</trigger>
>         <guard>...</guard>
>       </transition>
>       <transition>
>         <trigger>...</trigger>
>         <guard>...</guard>
>       </transition>
>     </next-state>
>     <next-state name="Z">...</next-state>
>   </state>
>   <state name="Y">
>     ...
>   </state>
></machine>
>
>There is a collection of states, some of which are reachable from
>other states.  To transition from one state to another, you must have
>both a triggering event and a satisfied guard condition.  Certain
>states can be tagged as "terminal", although I didn't.  Guard conditions
>can be complex, so in Paul's case, the waiter's arrival may trigger
>a change to the SALAD state, but if Paul hasn't finished his coffe
>(the guard), then the transition doesn't take place.  (Who ever heard
>of having coffer before salad?)
>
>Does this help, or do you need to see salad and coffee mixed in
>amonxt the XML tags?
>
>Walden Mathews