On 4/3/06, Fasihullah Askiri <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
