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

RE: Definition of Choreography

From: Sandeep Kumar <sandkuma@cisco.com>
Date: Sat, 19 Oct 2002 18:00:52 -0700
To: "Mathews, Walden" <walden.mathews@tfn.com>, "'Champion, Mike '" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>
Message-ID: <GEEIIPGIGJHOLHFLNCJAEEBACPAA.sandkuma@cisco.com>

Would like to see Exceptions paths as well modeled in the state machine
model
proposed below. IMHO, abnormal & alternate execution paths,
and defining compensating behaviors
on those is the critical part of any system.
Regards,
Sandeep Kumar


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Mathews, Walden
Sent: Saturday, October 19, 2002 4:14 PM
To: 'Champion, Mike '; 'www-ws-arch@w3.org '
Subject: RE: Definition of Choreography



>> -----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
Received on Saturday, 19 October 2002 21:01:32 GMT

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