commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ouyang, Landon - ES/RDR -Gil" <Landon.Ouy...@itt.com>
Subject RE: [SCXML] XML engine decoupled from code
Date Thu, 01 May 2008 23:56:11 GMT
Rahul,

Thanks for the response. I am now up and running with <invoke>
(somewhat) but the lack of synchronicity is causing me a few issues that
I hope you can help with.

First, is there a way for a state to invoke a method and then
unconditionally transition to another state? For example:

    <state id="GetOnlineRemote">
        <invoke targettype="java" src="GetOnlineRemote"/>
        <transition target="SteadyState" />
    </state>

*should* execute the GetOnlineRemote() method and then transition to
SteadyState. However, because invoke is asynchronous, only the
transition happens. Is there a solution to this besides firing a return
event in GetOnlineRemote and conditioning the transition to that event?

Second, I chained several states together before going back to our
steady state (the starting point for state transitions):

    <state id="GetAll">
        <invoke targettype="java" src="GetOnlineRemote"/>
        <transition event="s3d.ReturnToSteady"
target="GetTransmitterStateAll"/>
    </state>
    <state id="GetTransmitterStateAll">
        <invoke targettype="java" src="GetTransmitterState"/>
        <transition event="s3d.ReturnToSteady"
target="GetAntRotateAll"/>
    </state>
    <state id="GetAntRotateAll">
        <invoke targettype="java" src="GetAntennaRotating"/>
        <transition event="s3d.ReturnToSteady" target="GetWIPModeAll"/>
    </state>
    <state id="GetWIPModeAll">
        <invoke targettype="java" src="GetWIPMode"/>
        <transition event="s3d.ReturnToSteady" target="SteadyState" />
    </state>

All states fired the s3d.ReturnToSteady event at the end of execution.
When executed, each method invocation happens as desired and I verified
that the state machine returns to the steady state. However, after
execution none of the transitions from the steady state work anymore!
This only happens when I chained the states together instead of entering
one state and then immediately returning to the steady state. Any idea
what is going on?

--
Landon Ouyang
Member Technical Staff
ITT Electronics Systems, Radar Systems - Gilfillan
7821 Orion Ave,
Van Nuys, CA 91406
(818) 901-2982


-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Thursday, May 01, 2008 12:40 PM
To: Commons Users List
Subject: Re: [SCXML] XML engine decoupled from code

On 4/30/08, Ouyang, Landon - ES/RDR -Gil <Landon.Ouyang@itt.com> wrote:
> Rahul,
>
>  Thanks once again for the quick response.
>
>  Before reading your e-mail I had already decided to go with the
<invoke>
>  route for developing our implementation. I made our state machine
class
>  an invoker class and registered it with the SCXML executor. The
invoke()
>  method would trim the string passed in as the source parameter and
>  invoke the method similar to the AbstractStateMachine class. I am now
>  able to add statements in the XML that utilize the <invoke> tag to
>  invoke Java methods defined inside the state machine class.
>
>  I ran into a problem which leads me to believe I may have chosen the
>  wrong route: I cannot access the initiated values of the class!
<snip/>

As in static fields? Should be possible.


> For
>  example, the state machine needed access to the GUI to change various
>  widgets. I had a member assigned to the JFrame to accomplish this but
>  this member is now null in the invoked method even though I correctly
>  initialized it earlier! This never happened before until I
transformed
>  the state machine class to an invoker class. Is the Invoker object a
>  separate instance of the original state machine object?
>
<snap/>

Each <invoke> gets a new instance of the Invoker class. If you need to
"initialize" the instance with handles to other bits (such as a
JFrame, in this example), those need to be in the state machine's
Context and passed in as <param>s.

IOW, an example in code:

0) Say myJFrame is the frame
executor.getRootContext().set("frame", myJFrame);

1) Markup fragment
<invoke ...>
  <param name="frame" expr="frame"/>
  ...
</invoke>

2) In invoker#invoke(String src, Map params) .... params.get("frame")
gets you the frame.

Finally, as mentioned on the Commons SCXML homepage (and the spec in
progress), <invoke> is evolving.

-Rahul


>
>  --
>
> Landon Ouyang
>  Member Technical Staff
>  ITT Electronics Systems, Radar Systems - Gilfillan
>  7821 Orion Ave,
>  Van Nuys, CA 91406
>  (818) 901-2982
>
>  -----Original Message-----
>
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
>  Sent: Wednesday, April 30, 2008 11:15 AM
>  To: Commons Users List
>  Subject: Re: [SCXML] XML engine decoupled from code
>
>  On 4/29/08, Ouyang, Landon - ES/RDR -Gil <Landon.Ouyang@itt.com>
wrote:
>  > Ingmar,
>  >
>  >  Thanks for the response. Our state machine maps states to specific
>  >  activities. It does not use a listener or a timer but rather a
custom
>  >  class that utilizes an event stack for the firing of events within
>  the
>  >  state routines.
>  >
>  >  Your solution based on conditional transitions sounds like a
>  reasonable
>  >  one. Given this information there are a couple more questions I
have:
>  >
>  >  1) Is there a way to specify Java routines in the XML file to be
>  >  executed with the <onentry> tag? Possibly with <invoke>? We can
then
>  do
>  >  away with invoking state routine/handlers that are implemented in
our
>  >  class (similar to AbstractStateMachine).
>  >
>  <snip/>
>
>  Possible with either (<invoke> for long running semantics, custom
>  actions in <onentry> etc. for shorter routines).
>
>  Specifically to your <onentry> question, see:
>
>   http://commons.apache.org/scxml/guide/custom-actions.html
>
>  For custom actions, map Java exceptions to logical outcomes (events)
>  rather than throwing them.
>
>
>  >  2) If the answer to question 1 is true, can we fire events within
>  these
>  >  Java routines to determine the transitions within these states? If
>  true,
>  >  we can forego your "cond" solution and instead use the Java
routines
>  to
>  >  determine the paths our state machine takes.
>  >
>  <snap/>
>
>  There are two categories of events, external and internal / derived.
>  For custom actions, you can trigger derived events (add any events to
>  the derviedEvents collection in Action#execute(...) ).
>
>  If you must fire external events, then the semantics of <invoke> are
>  more suitable. Based on what I've read in this thread so far, I think
>  a custom action will do (and has a considerably simpler execution
>  model).
>
>  -Rahul
>
>
>  >  Thanks!
>  >
>  >
>  >  Landon Ouyang
>  >  Member Technical Staff
>  >  ITT Electronics Systems, Radar Systems - Gilfillan
>  >  7821 Orion Ave,
>  >  Van Nuys, CA 91406
>  >  (818) 901-2982
>  >
>  >
>  >
>  > -----Original Message-----
>  >  From: Ingmar Kliche [mailto:ingmar.kliche@googlemail.com]
>  >  Sent: Tuesday, April 29, 2008 1:16 PM
>  >  To: Commons Users List
>  >  Subject: Re: [SCXML] XML engine decoupled from code
>  >
>  >  Landon,
>  >
>  >  I'm not sure if your CheckRotation is really a state. To me it
sounds
>  >  more
>  >  like a guard condition (i.e. a condition) to decide which state to
>  enter
>  >  (e.g. the state machine is in state A and some event arrives -
which
>  one
>  >  ? -
>  >  then check the guard condition and decide to go to B or C). Could
you
>  >  elaborate a little on your state machine. What is the event which
>  >  is triggered? What drives your state machine? Is it a timer which
>  >  triggers
>  >  the engine on a regular basis? Or is it an external process that
>  sends
>  >  events, or is it some user input, ...?
>  >
>  >  The information which you need to check (i.e. bRotating) seems to
be
>  >  available in the container application (the one that embedds the
>  SCXML
>  >  engine). Isn't it possible to pass this information (bRotating)
along
>  >  with
>  >  the event (i.e. as payload of the event) into the engine
(something
>  like
>  >  triggerEvent("???", bRotation))? In this case you could access
>  bRotation
>  >  within the SCXML code:
>  >
>  >  <state id="A">
>  >    <transition event="???" cond="_eventdata.bRotation == true"
>  >  target="B"/>
>  >    <transition event="???" cond="_eventdata.bRotation == false"
>  >  target="C"/>
>  >  </state>
>  >
>  >  Or could you use a CustomAction to access bRotation?
>  >
>  >  There is certainly a solution for your problem, but it would help
(at
>  >  least
>  >  me) if you could describe a little more (if possible).
>  >
>  >  Best,
>  >  Ingmar.
>  >  2008/4/29 Ouyang, Landon - ES/RDR -Gil <Landon.Ouyang@itt.com>:
>  >
>  >  > Hi,
>  >  >
>  >  > A conceptual issue has arisen after creating a working
application
>  >  that
>  >  > uses the Commons SCXML engine.
>  >  >
>  >  > Based on what we want out of the engine, it is essentially
>  important
>  >  > that the code implementation (Java) is decoupled/independent of
the
>  >  > underlying engine (XML file).
>  >  >
>  >  > To illustrate the problems I encountered, here is an example:
there
>  is
>  >  a
>  >  > state called CheckRotation that can detect whether there is or
>  isn't a
>  >  > rotation. We need the ability for a developer to be able to
place
>  this
>  >  > state anywhere in the state machine (possibly multiple times)
and
>  >  direct
>  >  > the state machine based on one of the two outcomes without
having
>  to
>  >  > write any Java code; he should only have to edit the XML file.
For
>  >  > example, one path could be A -> CheckRotation -> C or D and
another
>  >  > could be E -> CheckRotation -> F or G.
>  >  >
>  >  > We can modify the Java code so the CheckRotation method could
fire
>  >  > different events to direct the path.
>  >  >
>  >  > if(PrevState == A)
>  >  > {
>  >  >        if(bRotating)
>  >  >                fireEvent(EVENT_C);
>  >  >        else
>  >  >                fireEvent(EVENT_D);
>  >  > }
>  >  > else if(PrevState == E)
>  >  > {
>  >  >        if(bRotating)
>  >  >                fireEvent(EVENT_F);
>  >  >        else
>  >  >                fireEvent(EVENT_G);
>  >  > }
>  >  >
>  >  > But this solution adds complexity and defeats the whole purpose
of
>  >  using
>  >  > the engine in the first place! The CheckRotation state would
need
>  >  > multiple conditional transitions defined (instead of two) in the
>  XML
>  >  > file and the Java code would be interlinked with the XML engine!
Is
>  >  > there a more proper solution to this issue?
>  >  >
>  >  > --
>  >  > Landon Ouyang
>  >  > Member Technical Staff
>  >  > ITT Electronics Systems, Radar Systems - Gilfillan
>  >  > 7821 Orion Ave,
>  >  > Van Nuys, CA 91406
>  >  > (818) 901-2982
>  >  >
>

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


This e-mail and any files transmitted with it may be proprietary and are intended solely for
the use of the individual or entity to whom they are addressed. If you have received this
e-mail in error please notify the sender. Please note that any views or opinions presented
in this e-mail are solely those of the author and do not necessarily represent those of ITT
Corporation. The recipient should check this e-mail and any attachments for the presence of
viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

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


Mime
View raw message