On 4/19/06, Nestor Urquiza <[EMAIL PROTECTED]> 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. > <snip/>
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. > <snap/> 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 state) 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, IMO. 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="event.foo" cond="pre-condition" target="S11"/> <!-- waiting for event.foo here --> </state> <state id="S11"> <!-- action state --> <onentry> <!-- Set of actions if pre-condition is satisfied --> </onentry> <transition cond="post-condition" target="S12"/> <!-- not waiting for an event here --> ... </state> <state id="S12"> ... </state> -Rahul [1] http://jakarta.apache.org/commons/sandbox/scxml/usecases.html [2] http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html > > Thanks, > Nestor > > [1] See thread named [SCXML] SCXMLListener Exception > Handling Question > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
