commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] patterns for bridging
Date Thu, 20 Apr 2006 06:12:08 GMT
On 4/19/06, Nestor Urquiza <> wrote:
> Hello guys,
> Recently Rahul gave an excellent list of some patterns
> to handle bridging[1].
> I am trying to bridge my "system" or "domain" layer to
> my "scxml engine".
> Could anyone please give advice about which of them
> [1] better fit my usecase:
> I need to be able to accept an http request, analyze
> if specific business rules (to be configured by means
> of conditions (guards) in an scxml file) apply, then
> execute some internal actions and then move to the
> proper final state.

A couple of usecases [1] are available on the website that
specifically deal with usages in the servlet container, the difference
would be that both are dealing with (view) navigation rules. The
general concept being that an SCXMLExecutor is available within a
session, and each request (potentially) affects the state machine for
its session -- and that concept still holds in your case. Both
usecases map states to activities (first pattern) because the
activities are homogeneous (Ex: In RDC usecase we always invoke a
speech component whose ID matches the state ID, so if the state
machine starts off in state "foo", the component with ID "foo" is
activated). Unclear what the actions and activities are in your case.

> Let us put an example:
> -current state is S10 that will go to S12 if event
> E101 is received and condition C1 is satisfied.
> -C1 should be true if the request come from a valid IP
> and the proper actions related to E1 were succesfully
> completed.
> So before starting to execute specific-code for E101
> the first part of C1 (validIP eq true) should be
> satisfied what makes the execution of specific-code
> dependant on a setting from the scxml file. Later when
> the specific-code finishes, the rest of the condition
> (E101 finished correctly) can be validated and the
> transition can occur.

Without actually dealing with the specifics of any example, lets look
at guard conditions that are not "atomic", meaning that the guard
condition is broken down into:

 * A pre-condition that is evaluated as soon as the event is received
 * A set of actions that need to performed if the pre-condition is satisfied
 * A post-condition that evaluates the logical outcome from the
actions performed (and hence the transition target i.e. the next

The reason I'm not taking up your specific example is because its
possible to say that IP-based restriction is really more of a
container provided service, for example, Tomcat remote host / address
valves [2], and that sort of beats the undercurrent of the question,

While you can hack most state machines to fit many topologies (such as
by having side-effects in guard conditions), the most widely accepted
solution to the above scenario is to introduce an additional "action
state", like so:

<state id="S10">
 <transition event=""
  cond="pre-condition" target="S11"/> <!-- waiting for here -->

<state id="S11"> <!-- action state -->
  <!-- Set of actions if pre-condition is satisfied -->
 <transition cond="post-condition"
  target="S12"/> <!-- not waiting for an event here -->

<state id="S12">



> Thanks,
> Nestor
> [1] See thread named [SCXML] SCXMLListener Exception
> Handling Question

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message