RE: [tamie] Preview of BP transforms to LTS (with limited visualization)

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

Dale:

As usual for any code generation, we need first to manually write the expected (to-be-generated) eTSL script from these LTS graphs.

I assume the following:
- the goal is to write a state machine in eTSL for each one of tehse graphs. Transitions are caused by events (i.e. exchanged messages or business docs)  
- "END states" are defined as states that are output nodes in the graph (I guess these are implicitly defined by nodes that do not "start" any edge, must be named "successXXX", "failureYYY".)

One approach illlustrated below, based on a subset of the LTS for "decision" process:

- Each state is represented by a short "Monitor script" of the form below.
- The transition(s) to the next state(s) is coded inside the monitor as event-driven (wait for an event then test its content).
- Note that these scripts don't really need an "exit" operation, if all monitors are scripted in a way that when reaching an "output" monitor (here Failure1 or Success1), the "calling" monitor does not have anything else to execute when the output monitor is complete and returns.
- syntax is speculative here on future eTSL improvements...
 

<!-- ================= state: PurchaseOrderRequestAndConfirm1 =================== -->
<monitor name="PurchaseOrderRequestAndConfirm1">
<param name="podata"/>
<param name="todateduration"/>
<param name="maxduration"/>
<catch> (wait for next event related to this P.O. ref ) </catch>
<switch>
	<case test="(protocol failure) OR (timeout condition))">
		<start mname="Failure1">
			<param name="podata">...</param>
		</start>
	<case test="(it is a Partial P.O. Response)">
		<start mname="CancelOrderActivity1">
			<param name="podata">...</param>
			<param name="todateduration">.(new value)..</param>
		</start>
	</case>
	<case test="(it is a Full P.O. Response)">
		<start mname="Success1">
			<param name="podata">...</param>
			<param name="todateduration">...</param>
		</start>
	</case>
	</case>
</switch>
</monitor>
<!-- ================= state: CancelOrderActivity1 =================== -->
<monitor name="CancelOrderActivity1">
<param name="podata"/>
<param name="todateduration"/>
<param name="maxduration"/>
<catch> (wait for next event related to this P.O. ref ) </catch>
<switch>
	<case test="(success event)">
		<start mname="Success1">
			<param name="podata">...</param>
		</start>
	</case>
	<case test="(protocol failure OR timeout)">
		<start mname="Failure1">
			<param name="podata">...</param>
		</start>
	</case>
</switch>
</monitor>
<!-- ================= state: Failure1 =================== -->
<monitor name="Failure1">
<param name="podata"/>
<exit status="failure">...</exit>
</monitor>
<!-- ================= state: Success1 =================== -->
<monitor name="Success1">
<param name="podata"/>
<exit status="pass">...</exit>
</monitor>


Jacques


-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com] 
Sent: Thursday, June 12, 2008 10:12 AM
To: tamie@lists.oasis-open.org
Cc: Nikola Stojanovic; Andreas Schönberger; Matthew Arrott; Monica J. Martin
Subject: [tamie] Preview of BP transforms to LTS (with limited visualization)

Hi

This message is concerned with compiling Business Process descriptions into testing/monitoring assertions in the ETSL language TaMie is developing.

In the attachments, I have provided 3 ebBP/BPSS 2.0 examples of purchase order management public process descriptions (also called choreographies, interaction protocols, etc.).

I have included the LTS (labeled transition systems) generated from these three examples that provides the "semantic" information about states, their transitions, and the labels (sets of first order expressions) for those transitions.

Finally I have included some drawings of the LTSes as (computer science sense) graphs.

The XSLTs for doing the transforms up to GXL (graph exchange language, which is used to input into the graphical tools) are available for the curious, but both incomplete and unpolished. (For GXL to JPGs conversions, I use a java graph tool built on open source JGraph API called JGraphPad; an input file in compressed gzip format is available if you want to edit the original diagrams, but you will need to download the tool off the net.)

Given these inputs, the next steps are to compile LTS information into ETSL code. I expect this process to help guide what needs to be added back into the LTS label fields to produce workable code. At present the information in the labels come from ebBP's DocumentEnvelopeLanguage or ConditionGuardLanguage. Other languages are allowed in ebBP, and the ones that are used can probably be expanded into XPath 2.0 and/or Xquery expressions by making use of additional information in the ebBP process description instances. However, I will need the TC members to help state what is needed/useful in order to get closer to working ETSL outputs.

Bye
Dale Moberg

PS You might notice that the transition and decision LTSes are structurally the same graphs and in fact, the choreographies only differ in terms of gateway diagrams, and not "substantially". This is another advantage of casting BP descriptions into the canonical LTS formats before translating into ETSL, IMO.