commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <nest...@yahoo.com>
Subject Re: [SCXML] patterns for bridging
Date Thu, 20 Apr 2006 10:34:29 GMT
--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:

> On 4/19/06, Nestor Urquiza <nestoru@yahoo.com>
> 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.
> 

I am implementing state oriented business application
protocol ("scxml engine" + "bridge") that in fact will
be used between others by http calls ("system") not
relevant the way ... it can be GET/POST/REST/SOAP or
whatever terminology someone can come for the same
"Receiving calls from a client and answering them via
HTTP". 

A given http-call can be executed only if certain
pre-conditions apply within a given state. If
conditions apply and the execution of the
specific-code related to the service requested is
succesful then the system can move to the next step.

The problem is not about matching states to activities
but the way activities are related to states and this
is there is an interdependency between them both.
Below I think you gave the response already ... I will
need to create an action state for each state I
already thought about to implement. 

Mapping then is ensured because my activities are
classes with the same name as the incomming event.

Could you think about an option to avoid action
states? 

> 
> > 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.
> 

It might be true my example was confusing and still
you got my point which is the important part
(pre-cond, spec-act, post-cond affected by the result
of spec-act and at the end state change) but just fyi
I am using a propietary kind of servlet container and
the IP-based restriction in my app must be done by the
app itself because it is based on several business
rules that simply cannot be inserted in the
configuration file of the servlet. I need an IP/client
filtering engine that should be part of the particular
application and not part of the servlet container.

> While you can hack most state machines to fit many
> topologies (such as
> by having side-effects in guard conditions), the

Interesting, given the fact that jexl supports method
invocation ... don't you think this is a way to avoid
to much descriptive information in the scxml file?

Consider the jexl expression for example: 
"validVar eq true and
contextObjectUsingTheEventName.execute()" 

Because of the simple and there you could ensure that
only if the first part is true (pre-cond) you call the
execute method of an object that is supposed to be in
the context and you know its name because it maps to
the state machine event-name and the http-call. The
result is a boolean that will complete the
post-condition and therefore you do not need an action
state.

In other words this is maybe answering the alternative
way I am looking for. And it is important to
understand that I am not after a side-effect but
specific-code in my case.

Where I can see an example or information about
implementing such a mechanism? This is having jexl
expression that executes some java code that returns
boolean and can be used for a condition. I opened
another thread and I see I have responses so let me
check out them ... it is precisely related to the
context that I thought I need to use for this scenario
in order to set up the object that the sate machine is
supposed to use. 

Is it something the engine is doing already or will
do?

> 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:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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


Mime
View raw message