OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: LTS scripting & feasibility uploaded


I have posted a little package (LTSworks.zip) illustrating how eTSM can apply to LTS monitoring/validation.
 
I consider this work as a piece of investigation about requirements.
 
http://www.oasis-open.org/apps/org/workgroup/tamie/document.php?document_id=28975
 
 
The package goes much further than previous email outlining how Dale LTS definitions can be translated into eTSM.
It also shows how the eTSM script (to be generated from the LTS definition) will be compiled into XSLT.
This XSLT compilation is actually executed here and produces the LTS results (results.xml) over a sample Event Board itself an XML file (testlog.xml).
 
My conclusions from this application work:
 
- the concept of Test Case is not to be equated with the concept of "monitor" defined as a unit of workflow thread. The Test Case (or Monutor Case, or TM-Case...)  that corresponds to the monitoring of a multi-message transaction (see these transactions in testlog.xml), involves several monitors, as this is my recommendation for translating LTS graphs - one monitor to manage each node or state of the graph.
 
- multiple assignements of the same variable as well as EXIT for the entire Test Case instance, can be emulated in XSLT (in spite of XSLT model).
 
 
 
NOTES about concurrency and XSLT:
 
In my example, all the monitors involved execute sequentially, not concurrently, simply because of the template execution model of the XSLT processor. But my hunch is that this does not prevent from "emulating" an actual concurrent execution of monitors. Something like an AND-join would be scripted as usual by catching (waiting) for all end events posted by each "concurrent" thread to be joined, even if these execute actually in sequence.
 
A difficulty arise with OR joins and XOR joins, as you do not know which monitor execution will "succeed" and yet if each one of the forked monitors are catching events along the way, you do not want the failed or hanging sequential execution of one of them to block the others from catching theirs. That could be the case if we wanted to "XOR-join" the CancelOrder path and the Success0 path in our LTS example. That calls for a sort of "pooling" of CATCHER templates in XSLT,  derived from all CATCHER eTSM operations that are supposed to execute concurrently. That will be a compilation challenge in XSLT though not an impossible one I believe. See my "pooling" of catching either the POresponse "partial" event of the POresponse "full" event , whichever comes first. This corresponds to an XOR forking.
 
Jacques


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]