RE: Definition of Choreography

 

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