- 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>
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 UTC