commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fasihullah Askiri" <fasihullah.ask...@baypackets.com>
Subject RE: [SCXML] Same event to multiple parallel states
Date Mon, 03 Apr 2006 22:52:42 GMT
<snip>
 * If a "line" from your snippet earlier is a "call", then the correct
way to handle the events is per a SessionManager. Whether we're using
HTTP and the servlet API (see usecases on the web site) or some
protocol of choice over a SIP-based communication channel, bookkeeping
for the events and sessions / calls has to be done at the "container"
level, rather than by Commons SCXML.
</snip>
Could not really get this. Can you explain? By the way, I am using a SIP stack to do the dialog
management.

+Fasih

-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Monday, April 03, 2006 5:17 PM
To: Jakarta Commons Users List
Subject: Re: [SCXML] Same event to multiple parallel states


On 4/3/06, Fasihullah Askiri <fasihullah.askiri@baypackets.com> wrote:
> Thanx Rahul
> That was really quick. I was thinking about the payload option yesternite, there is a
glitch in that. As you can see, for every event I will have to keep the cond, now that sounds
perfectly logical, but given my use-case that seems unneseccary. Again, coming back to my
use-case, I want to test my application server; I am trying to use scxml to simulate a UA
with different behaviours, further down the line I will integrate this with DBUnit to figure
out if the call rating/charging, cdr etc have been written properly or not. I am not very
sure if SCXML is the right thing to do this, but it does provide a solution which would be
very convenient to simulate different call scenarios. Given that, adding conds does not sound
very intutive.
>
> This is another solution I was thinking of, again, I am just thinking aloud, not really
thought of pros/cons of the solution:
>
> Have a scenario.xml with names&scxml for each scenario. Have a SessionManager to
load each of these scxml and ascociate it with a sip dialog. Keep the root context same for
each of the Executor to aid in data sharing if required. Now when an event comes, instead
of "broadcasting" it to all lines, send it to the exec concerned [known to the scenario manager].
This makes each scenario stand-alone, and gives all the flexibility that SCXML has to give
minus the conds which are introduced coz I have designed it that way.
>
> Any comments welcome.
>
<snip/>

While I won't claim to have grasped all the details for your usecase,
I will agree on the following points:

 * Since a state chart models a *single* behavior, trying to emulate
different agent behaviors will require different state charts. Any
SCXML document, however, needs to be parsed only once, so creating
multiple UAs with identical behaviors requires only one crank at
parsing, which is arguably the most expensive operation in the Commons
SCXML pipeline.

 * If a "line" from your snippet earlier is a "call", then the correct
way to handle the events is per a SessionManager. Whether we're using
HTTP and the servlet API (see usecases on the web site) or some
protocol of choice over a SIP-based communication channel, bookkeeping
for the events and sessions / calls has to be done at the "container"
level, rather than by Commons SCXML.

I will also differ on the following point:

 * Contexts should never be shared. Even if you want to share data,
create a new root context and trivially populate it with the "shared
variables". Root contexts store a number of "special" / reserved
variables as required by the SCXML WD. Nothing good will come out of
these stepping on each others' toes for separate sessions / executions
;-)

Hope that helps,
-Rahul


> +Fasih
>
>
<snap/>

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


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