[SCXML] Question save/restore state of FSM

[Daniel Schwager]

Hi Rahul,

i'm testing/learning/playing around SCXML for about 2 days now. First
of all - great work of this java port (-:

There are two questions i can't find an answer to:

a) Could I realize a transition guarded with a condition checking
   a substate of a parallel state ?
        <parallel>
                <state 1>
                        <state11/>
                        <state12/>
                        <state13/>
                </state1>
                <state2>
                        <transition event="a" target="state2"
cond="statemachine is in state state1.state12"/>
                <state2/>
        <parallel/>


B) i would like to save/restore my FSM (using the SCXML in
EJB3-container with session beans)
Therefore I look around (found also SCXML-19 ..). I realized another
way, but this one
does not work correctly - there's a problem restoring the state ...
maybe you can help me ?


--------------------------------------------------------------------

//Each trigger instances a new Executor, load the old context to it and
fire the event:

Public void myOwnTrigger(Object sm, Trigger evt) {
                        // Object sm is persistent (loadding before
calling myOwnTrigger() ans saveing after calling ..)

                        SCXMLExecutor exec = new SCXMLExecutor();
                        exec.setStateMachine(static-scxml-strng);
                        exec.setRootContext(sm.getRootContext);
// !! I use a "persistente" root context
                        exec.setEvaluator(new evaluator);
                        exec.setErrorReporter(new errReporter);
                        exec.setEventdispatcher(new
StateMachineEventDispatcher(sm));

// After this, i only added the Listeners immediately, if the FSM never
runs before
                        if (!sm.isInitialized()) {
                                // First time - invoke Listener also
                                exec.addListener(scxml, new
SimpleSCXMLListener());
                                exec.addListener(scxml, new
StateMachineEntryListener(sm));
                                sm.setInitialized(true);
                                exec.go();

// Else, I installed the listeners AFTER exec.go() to prevent to
re-invocations of business method's still done
                        } else {
                                // still initialized - involke listener
after FSM is initialized
                                // (going through all states ..)
                                exec.go();
                                exec.addListener(scxml, new
SimpleSCXMLListener());
                                exec.addListener(scxml, new
StateMachineEntryListener(sm));
                        }

// Finally, trigger the event
                        exec.trigger(evt)
                        return;

--------------------------------------------------------------------

But if i fire _TWO_ "watch.start" to the model
        <state id="stopwatch">
                <initial>
                        <transition target="reset" />
                </initial>

                <state id="reset" final="true">
                        <onentry/>
                        <transition event="watch.start" target="running"
/>
                </state>

                <state id="running">
                        <onentry/>
                </state>
        </state>


my solution results in
        ****************** FIRE EVENT 1
        I'm in stopwatch
        I'm reset
        I'm running
        INFO: State(reset) State(stopwatch)
        ****************** FIRE EVENT 2
        I'm running
        INFO: State(reset) State(stopwatch)

The correct solution (with the normal way using exec.go() and 2 x
exec.trigger(evt) results in
        I'm in stopwatch
        I'm reset
        I'm running
        INFO: State(stopwatch) State(running)

--> My solution enters the "running" state twice, because the state does
not
    change from reset->running.... (printed after a new instance of
exec, after exec.go() loaded with the "persistent" context)
   
    Why ? Is there more to save beside of exec.getRootContext() ???

Best regards
Danny




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Rahul Akolkar]

On 6/30/08, Daniel Schwager <Daniel.Schwager@...> wrote:

> Hi Rahul,
>
>  i'm testing/learning/playing around SCXML for about 2 days now. First
>  of all - great work of this java port (-:
>
>  There are two questions i can't find an answer to:
>
>  a) Could I realize a transition guarded with a condition checking
>    a substate of a parallel state ?
>         <parallel>
>                 <state 1>
>                         <state11/>
>                         <state12/>
>                         <state13/>
>                 </state1>
>                 <state2>
>                         <transition event="a" target="state2"
>  cond="statemachine is in state state1.state12"/>
>                 <state2/>
>         <parallel/>
>

<snip/>

Use the In() predicate like so:

... cond="In('state12')" ...

>
>  B) i would like to save/restore my FSM (using the SCXML in
>  EJB3-container with session beans)
>  Therefore I look around (found also SCXML-19 ..). I realized another
>  way, but this one
>  does not work correctly - there's a problem restoring the state ...
>  maybe you can help me ?
>
>
>  --------------------------------------------------------------------
>
>  //Each trigger instances a new Executor, load the old context to it and
>  fire the event:
>
>  Public void myOwnTrigger(Object sm, Trigger evt) {
>                         // Object sm is persistent (loadding before
>  calling myOwnTrigger() ans saveing after calling ..)
>

<snap/>

In order of preference:

1) Persist the SCXMLExecutor instance below, instead of merely the root context.

2) Correctly set the states collection of the current executor status
[ exec.getCurrentStatus().getStates() ] along with its root context

-Rahul

>                         SCXMLExecutor exec = new SCXMLExecutor();
>                         exec.setStateMachine(static-scxml-strng);
>                         exec.setRootContext(sm.getRootContext);
>  // !! I use a "persistente" root context
>                         exec.setEvaluator(new evaluator);
>                         exec.setErrorReporter(new errReporter);
>                         exec.setEventdispatcher(new
>  StateMachineEventDispatcher(sm));
>
>  // After this, i only added the Listeners immediately, if the FSM never
>  runs before
>                         if (!sm.isInitialized()) {
>                                 // First time - invoke Listener also
>                                 exec.addListener(scxml, new
>  SimpleSCXMLListener());
>                                 exec.addListener(scxml, new
>  StateMachineEntryListener(sm));
>                                 sm.setInitialized(true);
>                                 exec.go();
>
>  // Else, I installed the listeners AFTER exec.go() to prevent to
>  re-invocations of business method's still done
>                         } else {
>                                 // still initialized - involke listener
>  after FSM is initialized
>                                 // (going through all states ..)
>                                 exec.go();
>                                 exec.addListener(scxml, new
>  SimpleSCXMLListener());
>                                 exec.addListener(scxml, new
>  StateMachineEntryListener(sm));
>                         }
>
>  // Finally, trigger the event
>                         exec.trigger(evt)
>                         return;
>
>  --------------------------------------------------------------------
>
>  But if i fire _TWO_ "watch.start" to the model
>         <state id="stopwatch">
>                 <initial>
>                         <transition target="reset" />
>                 </initial>
>
>                 <state id="reset" final="true">
>                         <onentry/>
>                         <transition event="watch.start" target="running"
>  />
>                 </state>
>
>                 <state id="running">
>                         <onentry/>
>                 </state>
>         </state>
>
>
>  my solution results in
>         ****************** FIRE EVENT 1
>         I'm in stopwatch
>         I'm reset
>         I'm running
>         INFO: State(reset) State(stopwatch)
>         ****************** FIRE EVENT 2
>         I'm running
>         INFO: State(reset) State(stopwatch)
>
>  The correct solution (with the normal way using exec.go() and 2 x
>  exec.trigger(evt) results in
>         I'm in stopwatch
>         I'm reset
>         I'm running
>         INFO: State(stopwatch) State(running)
>
>  --> My solution enters the "running" state twice, because the state does
>  not
>     change from reset->running.... (printed after a new instance of
>  exec, after exec.go() loaded with the "persistent" context)
>
>     Why ? Is there more to save beside of exec.getRootContext() ???
>
>  Best regards
>  Danny
>
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: user-unsubscribe@...
>  For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Daniel Schwager]

> >  B) i would like to save/restore my FSM (using the SCXML in
> >  EJB3-container with session beans)
> >

> In order of preference:
>
> 1) Persist the SCXMLExecutor instance below, instead of merely the
root context.
>
> 2) Correctly set the states collection of the current executor status
> [ exec.getCurrentStatus().getStates() ] along with its root context
>

Hi Rahul,

if i persist the SCXMLExecutor instance, I will also persist all the
injected codeeobjects like
        Evaluator
        ErrorReporter
        Eventdispatcher
        All Listeners

also. IMHO, it's better to choose your second way.

Now the code works:


                        // init exec
                        ....

                        if (!sm.isInitialized()) {
                                // First time - invoke Listener and
reset FSM
                                exec.addListener(scxml, new
SimpleSCXMLListener());
                                exec.addListener(scxml, new
StateMachineEntryListener(sm));
                                sm.setInitialized(true);
                                exec.go();

                        } else {
                                // reload the states
       
exec.getCurrentStatus().getStates().clear();
       
exec.getCurrentStatus().getStates().addAll(sm.getStates());

                                exec.addListener(scxml, new
SimpleSCXMLListener());
                                exec.addListener(scxml, new
StateMachineEntryListener(sm));
                        }

                        exec.triggerEvent(evt);

                        // Save states
                        sm.getStates().clear();
       
sm.getStates().addAll(exec.getCurrentStatus().getStates());

Thanks very much

Regards
Danny from softwaredemo.de (running SCXML inside ;)


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Rahul Akolkar]

On 7/1/08, Daniel Schwager <Daniel.Schwager@...> wrote:

> > >  B) i would like to save/restore my FSM (using the SCXML in
>  > >  EJB3-container with session beans)
>  > >
>
>
> > In order of preference:
>  >
>  > 1) Persist the SCXMLExecutor instance below, instead of merely the
>  root context.
>  >
>  > 2) Correctly set the states collection of the current executor status
>  > [ exec.getCurrentStatus().getStates() ] along with its root context
>  >
>
>
> Hi Rahul,
>
>  if i persist the SCXMLExecutor instance, I will also persist all the
>  injected codeeobjects like
>         Evaluator
>         ErrorReporter
>         Eventdispatcher
>         All Listeners
>
>  also. IMHO, it's better to choose your second way.
>
>  Now the code works:
>

<snip-code/>

In some scenarios ;-)

I will point out that this doesn't persist some interesting bits such
as (not a complete list):

 * Histories (i.e. if you use <history>)
 * Contexts other than the root context (i.e. if you use <cs:var> etc.)
 * Invokers (i.e. if you use <invoke>)

If you want to avoid persisting the "injected" bits, I'd suggest
"hollowing them out" before persisting, so:

 * Use removeListener(...) for addListener(...) before persisting
 * Use a lazy initializations (or inject by means available)
Evaluator, ErrorReporter. (or even set them to null before persisting)

This would be a more robust approach IMO.


>  Thanks very much
>
>  Regards
>  Danny from softwaredemo.de (running SCXML inside ;)
>
<snap/>

Cool, if you want to be listed in the "Who is using it?" section on
the Commons SCXML homepage [1] (see bottom of page), post (on this
list) a link and a descriptive sentence about the use to go with it.

-Rahul

[1] http://commons.apache.org/scxml/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Daniel Schwager]

> I will point out that this doesn't persist some interesting bits such
> as (not a complete list):
>
>  * Histories (i.e. if you use <history>)
>  * Contexts other than the root context (i.e. if you use <cs:var>
etc.)
>  * Invokers (i.e. if you use <invoke>)
>

I saw these hints while scanning your code (-:
At the moment, it works - if I use starting history-functionality,
I will recode the persistence as you suggested ..

> >  Danny from softwaredemo.de (running SCXML inside ;)
>
> Cool, if you want to be listed in the "Who is using it?" section on
> the Commons SCXML homepage [1] (see bottom of page), post (on this
> list) a link and a descriptive sentence about the use to go with it.

Sure - please wait until we launch the service (in about 1-2 weeks).
If you want, I can integrate your SCXML later in our netbeans-6.1
running on opensolaris
for the community on softwaredemo.de (-:

Regards
Danny


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Rahul Akolkar]

On 7/1/08, Daniel Schwager <Daniel.Schwager@...> wrote:
<snip/>

>  > >  Danny from softwaredemo.de (running SCXML inside ;)
>  >
>
> > Cool, if you want to be listed in the "Who is using it?" section on
>  > the Commons SCXML homepage [1] (see bottom of page), post (on this
>  > list) a link and a descriptive sentence about the use to go with it.
>
>
> Sure - please wait until we launch the service (in about 1-2 weeks).
>  If you want, I can integrate your SCXML later in our netbeans-6.1
>  running on opensolaris
>  for the community on softwaredemo.de (-:
>

<snap/>

Even better if you can give something back to the community :-) So
just ping this mailing list when you're ready and want to suggest an
entry in the "whos using it" section.

-Rahul



>  Regards
>  Danny
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...