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

RE: Definition of Choreography

From: Mathews, Walden <walden.mathews@tfn.com>
Date: Sun, 20 Oct 2002 08:29:50 -0400
Message-ID: <1373D6342FA1D4119A5100E029437F64045EEE1F@clifford.devo.ilx.com>
To: "'Ricky Ho '" <riho@cisco.com>, "Mathews, Walden" <walden.mathews@tfn.com>, "''Champion, Mike ' '" <Mike.Champion@SoftwareAG-USA.com>, "''www-ws-arch@w3.org ' '" <www-ws-arch@w3.org>

 

>-----Original Message-----
>From: Ricky Ho
>To: Mathews, Walden; 'Champion, Mike '; 'www-ws-arch@w3.org '
>Sent: 10/20/2002 2:37 AM
>Subject: 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.

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.


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

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

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

That would be a bad idea (to model exception handling as its own set
of states) for reasons already put forth.  Exceptions are, by definition,
"short run" processes.  States in a FSM are intended to be "stable" or
"long run" processes.  That would be unnecessary implementation-oriented
clutter.

Walden
Received on Sunday, 20 October 2002 08:30:37 GMT

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