concurrent scriplet flows vs. XSLT translation

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

Use Case #2 is much more interesting and valuable than I thought at first.

It deals with several issues not addressed bu UC#1, although both UC definitions seem very close.

 

An remarquable aspect of UC2 is that asynchronous scriplet execution is the natural way to script it - makes the scripting much easier than say using a conventional prog language:

 

- a main loop is iterating over all PO events filed over a month period.

- inside the loop, for each PO, another scriplet (monitorPOtransaction) is started that will monitor this particular PO transaction i.e. wait for related messages, error or responses, check the timing, etc. This scriplet will therefore catch its own events, but should not block the main loop which waits for the next PO. It must then be started with @async="true".

 

This concurrent execution (one main scriplet + many instances of monitorPOtransaction, all concurrent) may seem at first quite a challenge for XSLT translatability.

However, under some restrictions that are still very acceptable for many applications, translatability is easy to achieve:

- when executing on logs of events that have already occurred  ("stale" execution, not live).

- when the scripts do not consume events that it posts itself (i.e. a test script does not use events for synchronizing the concurrent execution of its own scriplets, like in thread programming. But its OK to post events as "output")

 

Under these conditions, the concurrency of UC#2 is quite translatable in plain XSLT: all scriplet executions will in fact be serialized. Concurrency is simulated as a game of setting the "time cursor" at the right date/time when starting each new scriplet or when continuing the spawning scriplet.

 

This is good news for an XSLT ref implementation of eTSM.

 

-Jacques

 

 

 

---

From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
Sent: Saturday, April 04, 2009 5:21 PM
To: tamie@lists.oasis-open.org
Subject: [tamie] Use Case #2 script proposal posted in wiki

Use Case #2 script proposal posted in wiki

 

http://wiki.oasis-open.org/tamie/UC2-Proposal1

 

General comments on this solution:

• 1. executionContext: this concept allows to specify how the scriplets bind to
  • a specific execution (or monitoring) environment, keeping them as generic as possible. It specifies bindings of different kinds: namespaces, event boards. It specifies which scriplet should be executed initially. That is also where some global variable value could be specified.

• 2. Event board: use of a specific "PurchaseOrder" event board in addition to the

  • "main" event board. This PO event board is "declared" in the executionContext. This declaration is NOT processed by the scriplets, but by whatever component is posting the events - an event manager. The event manager uses the filters defined in the declaration to dispatch the events to the right event board. In addition, the declared PO event board is indexed: a key expression is defined, that allows events to be indexed (the CATCH will be able to perform fast within all events associated with same key.)
• 3. loop: Full use of eTSM iteration features is made here, with "loop variables"

  • necessary to gather stat data. The <nextval> statement has been renamed <nextloop> and revised: It is suggested here to be a wrapper for reassignment of (several) loop vars, because these may require additional constructs, like here conditionals. This wrapper needs to be placed at the end of the loop body, just before the <onfinal> statement if any.

• 4. async scriplet exec: note that the monitorPOtransaction is invoked asynchronously.
  • Indeed it is going to "wait" for some events related to each particular PO, and this wait should not affect the main loop catching every PO. (If it were invoked "synchronously" then the next PO catch would occur after its execution and we would "loose" all POs occurring in-between).
• 5. date-time functions: several date functions of the (rich) library of XPath2 functions
  • are used here. Very promising for eTSM testing / monitoring objectives.
• 6. effect of exit: when a scriplet exits, its only effect is the one caused by
  • the exit statement. The effect of exit is represented by the XML fragment inside it, wrapped by an <exit> element with same attributes

-Jacques