- From: Mathews, Walden <walden.mathews@tfn.com>
- Date: Sun, 20 Oct 2002 08:29:50 -0400
- 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 UTC