commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [SCXML] Event types
Date Thu, 24 May 2007 21:46:16 GMT
On 5/24/07, Nestor Urquiza <nestoru@yahoo.com> wrote:
> Yes, I remember that one a year ago when I started my project ... the Domain/Bridge/Engine
definition convinced me this was the API I was looking for when deciding how to implement
a state oriented business protocol.
>
> In fact the idea of using err.app came from that or another related post as far as I
remember. The proposed solution is then to manage with thrown by the application events (from
custom actions) where to go but as discussed before it won't mean that the rest of the code
within the onentry state won't be executed.
>
> See the following example (borrowed from your post and arbitrarly changed to demonstrate
the issue):
>
> <state id="foo">
>
>   <onentry>
>
>     <my:action ... />
>
>     <my:action2 ... />
>   </onentry>
>
>   <transition event="err.foo" target="errorstate" />
>
>   <n:transition cond="resultFromAction2 eq true" target="bar"/>
>   <!-- other transitions etc. -->
>
> </state>
>
>
> If "action" somehow manages its exceptional situation throwing "err.foo" event it wont
stop execution of "action2". Furthermore since chances are more than one transition conditions/events
could be stisfied the FSM could go to two different states at the same time (errorstate and
bar) which of course is not what we want.
>
> Our target is just to stop action, do not execute action2 and ensure *only* event err.foo
is processed as part of the transitions (perhaps because of the fact that it has a higher
priority as suggested before).
>
> Does it make sense?
>
<snip/>

Yes. However, I think the reason why the above seems intractable is
because in this case the state machine is not adhering to one of the
assumptions of executable content in onentry/exit. Such executable
content is assumed to be atomic and side-effect free as far as the
progress of the state machine is concerned. What is perhaps possible
here is to separate state "foo" into state "foo1" (which holds
<my:action> in its onentry, resulting in either "done.foo1" or
"err.foo1" depending on the success or failure of  the action) and
state "foo2" (which holds <my:action2> and transitions from original
"foo" state etc.). Depending on the specifics of the state machine,
some other adjustments may be necessary.

-Rahul


> Thanks,
>
> -Nestor
>
> ----- Original Message ----
> From: Rahul Akolkar <rahul.akolkar@gmail.com>
> To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> Sent: Thursday, May 24, 2007 4:10:28 PM
> Subject: Re: [SCXML] Event types
>
> On 5/22/07, Nestor Urquiza <nestoru@yahoo.com> wrote:
> > Could you mention in your opinion at least one of the alternatives to modify or
create a new SCXML Semantic implementation to deal with critical errors that are supposed
to stop the normal flow of the application? The Event type could be one that we already saw
is not going to be provided within the library and still seems like the best way to accomplish
that goal.
> >
> <snip/>
>
> I think this was discussed a couple of times so I tried to look it up
> in the archives, though I can only find one reference ATM (see about a
> third of the way down in following email):
>
> http://www.nabble.com/Re%3A--SCXML--SCXMLListener-Exception-Handling-Question-p3604935.html
>
> That along with a couple of related observations ...
>
>  * Stopping a flow is equivalent to redirecting it to a (different)
> final state (than what is perceived "normal")
>  * Each event name, by itself, specifies a unique "type" of event
>
> ... should satisfy many usecases.
>
> -Rahul
>
>
> > Thanks,
> >
> > -Nestor
> >
> <snap/>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message