Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of rahul.akolkar@gmail.com
 designates 72.14.220.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Smp5UBE7wnRcwE0Txdx/gaSQ16+wQmfUNS64dMSUfjhCP3lUdJdHuTIfGPruZbAacfLdsB0JYYe6UEdlbC8uhGD7/4k8wi5GdXp9mGV7Socv3lXPqMmEUYmisFFS+MhE6mE3Ae2zQHBbQ0LUTonqoYjTnGWjAOJZSFRpECKByxw=
Message-ID: <ce1f2ea80804181712m7c80b611w3c1cc6e91c8c1d67@mail.gmail.com>
Date: Fri, 18 Apr 2008 20:12:32 -0400
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <user@commons.apache.org>
Subject: Re: [SCXML] State transitions from within handler
In-Reply-To: 
 <BDDC2E39D59D4D48984BB961677A2F10433A48@vnexch01.gilfillan.de.ittind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <BDDC2E39D59D4D48984BB961677A2F104336D8@vnexch01.gilfillan.de.ittind.com>
	 <BDDC2E39D59D4D48984BB961677A2F10433737@vnexch01.gilfillan.de.ittind.com>
	 <BDDC2E39D59D4D48984BB961677A2F1043373F@vnexch01.gilfillan.de.ittind.com>
	 <ce1f2ea80804111417j6bd29191xcb60d34b1c9378cf@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F1043375C@vnexch01.gilfillan.de.ittind.com>
	 <ce1f2ea80804111855q2fddc8acxb99f1a3ea4a3fb84@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F104337A2@vnexch01.gilfillan.de.ittind.com>
	 <BDDC2E39D59D4D48984BB961677A2F104337B3@vnexch01.gilfillan.de.ittind.com>
	 <ce1f2ea80804141218v9374d4cp3884ddc07487586c@mail.gmail.com>
	 <BDDC2E39D59D4D48984BB961677A2F10433A48@vnexch01.gilfillan.de.ittind.com>

On 4/17/08, Ouyang, Landon - ES/RDR -Gil <Landon.Ouyang@itt.com> wrote:
> Hi Rahul,
>
>  Thanks for your informative response.
>
>  Using your suggestions I created my own state machine class that did not
>  utilize a listener. I overwrote the Initialize() and fireEvent()
>  routines to invoke the state methods and utilize an event stack to
>  process external events.
>
>  The only issue with my implementation is that an event must be fired for
>  a state method to be invoked. For example, if we make state 4
>  automatically (unconditionally) transition to state 5 in the SCXML file,
>  state5() will not be called. It will only be called if we fire an event
>  in state 4 to transition to state 5.
>
>  Is there a place where I can call invoke() in the state machine
>  implementation (without a listener) so that the state handler is called
>  on a transition regardless of whether an event was fired or not?
>
<snip/>

You could register a listener simply to track the progress, especially
when eventless transitions are involved as you describe (and refer to
this list to invoke state "handlers" in order). Alternatively, you
could guard the previously eventless transitions with a special event
(some event name TBD) that you fire at the end of the preceeding state
handler.

-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: Monday, April 14, 2008 12:19 PM
>  To: Jakarta Commons Users List
>
> Subject: Re: [SCXML] State transitions from within handler
>
>  On 4/14/08, Ouyang, Landon - ES/RDR -Gil <Landon.Ouyang@itt.com> wrote:
>  > Rahul,
>  >
>  >  Thanks for your help, I was able to implement the state transition
>  >  method you had described earlier.
>  >
>  >  The reason for this investigation is that we intend to use the
>  Commons
>  >  SCXML engine to implement highly complex systems by separating all
>  the
>  >  "pieces" into atomic modules (states).
>  <snip/>
>
>  Makes sense, for very simple systems [scxml] may even be overkill.
>
>
>  >  However, we would like the
>  >  decision making for the transitions to be done within the application
>  >  code (state handlers) and not the state machine implementation (XML).
>  We
>  >  foresee problems if the XML document must specifically reference the
>  >  attributes needed to decide which transitions occur (ie
>  'result.value'
>  >  in our earlier example).
>  >
>  <snap/>
>
>  OK, though I don't necessarily agree. Couple of points:
>
>   * IMO, in highly complex systems the declarative vocabulary (be it
>  XML or otherwise) can be thought of as merely a serialization of some
>  model (such as the domain UML2 state charts) which the developer(s)
>  maintain.
>
>   * The [scxml] library can be the basis of building components that
>  serve to wrapper certain conventions in place over the state machine
>  implementation -- conventions that mitigate problems in having to
>  "specifically reference the attributes needed". The
>  AbstractStateMachine is one such simple example (uses a convention to
>  call "state handlers"). However, it has drawbacks (such as invoking
>  handlers synchronously while processing events) and is not fit for
>  complex systems.
>
>
>  >  The only way I can think around this problem is to create a custom
>  >  transition/event stack in which the next event gets pushed during the
>  >  state handler and popped once we are officially in the current state
>  >  (since the previous state is still being processed while we are in
>  the
>  >  handler).
>  >
>  <snip/>
>
>  May not be necessary. The following suggested replacements is how I
>  have understood the sentences in the above paragraph:
>
>  s/officially in a state/at rest in a state/
>  s/previous state is being processed/previous event is being processed/
>
>
>  >  Is there a better way around this issue? If not, where in
>  >  AbstractStateMachine will I know for a fact that the previous state's
>  >  processing has been completed?
>  >
>  <snap/>
>
>  See this page:
>
>   http://commons.apache.org/scxml/guide/using-commons-scxml.html
>
>  The AbstractStateMachine uses the second pattern. One of the ways to
>  achieve what you want is using the first pattern, "Mapping states to
>  activities" (current state --> state handler).
>
>  Create a variant that bootstraps similar to the AbstractStateMachine
>  class, waits for state machine to come to rest (initially, and when
>  any subsequent event is triggered on it), looks up current state
>  (rather than registering a listener that gets called synchronously),
>  and calls the corresponding state handler. Maintain a queue for
>  external events, have state handlers add to that queue, trigger events
>  in order while queue not empty. Adjustments necessary per taste etc.
>  :-)
>
>  -Rahul
>

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