commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <nest...@yahoo.com>
Subject Re: [SCXML] Event types
Date Fri, 25 May 2007 10:15:14 GMT
Hi Rahul,

IMHO in order to use SCXML as a WEB Controller I would say non atomic and side effect activities
should be allowed within onEntry and onEntry events. This might be violating the whole Harel
State theory ... I really do not knoiw ... but from a protocol perspective states are most
likely related to results of interactions between the two peers and those interactions will
have side effects for the state machine execution which I understand I can accomplish using
scxml "if" statements of course but definitely an exception handling mechanism would be handy.

I understand there is a solution to make activities atomic operations and so create pseudostates
or multiple states but that option complicates maintanance and reuse of code for a WEB domain.

For the main domain SCXML was created, I mean VXML it can be not that difficult to manage
the whole application with thousand states. For a WEB application though the path would be
extremely hard and will start giving more issues that advantages over other MVC solutions.

As said before I am managing the logic using if statements. It would be great to have an event
priority solution that will allow the logical execution to be stopped when an abnormal situation
occurs.

Thanks a lot!!!

Regards,

-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 5:46:16 PM
Subject: Re: [SCXML] Event types

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






       
____________________________________________________________________________________Sick sense
of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222

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