about the role(s) of LTS

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

Dale:

 

following-up on today's call:

 

I think it is good to "standardize" a bit the LTS to be used as a starting point for UC3 (i.e. define a reusable mark-up).

 

But as mentioned, LTS does not have detailed info such as message protocol info, nor how to correlate messages.

 

Yet as a starting point for scripting UC3, it would be good to start from an "augmented" LTS definition, if only to guarantee that the way we script it is systematic, even if we only do it manually at first.

Because the ultimate goal is later to generate the eTSM from this augmented LTS.

 

 

So I'd propose to that we consider two LTS representations:

 

- the "abstract" LTS, which describes the state transition graph (e.g. for UC3), but ignores some mundane details like message protocol and message correlation. The abstract LTS is the first step in handling various BPM or choreography definitions..

 

- the "concrete" LTS, which is an augmentation of the same mark-up used in the abstract LTS. It contains all details needed for use as an input to an eTSM generator. Here we should probably restrict the scope to handle only the case where messages = XML material ( meaning assume an XML formatting  of any HTTP or MIME envelope, in case we need to express conditions or do correlation at this level). The "concrete LTS" for XML events can then standardize on the use of XPath to express transitions and correlations.

 

Someone could later write a translator abstract --> concrete, based on contextual info such as "messages are SOAP extended with WS-Addressing for correlation", or "messages are ebMS V.123" or "WS-BPEL correlation-sets are used, and they are..." etc.

 

 

Below is a sample of what the Concrete LTS could look like: I have written a corresponding eTSM code a few months ago as well as the corresponding XSLT script that I executed successfully. Although I have not written the translator LTS --> eTSM  nor eTSM --> XSLT, I am confident there is enough information at each level to do that:

 

Concrete LTS:

 

(NOTE: the content of <event> is XPath, so is the <correlation> element. This notation allows to represent correlation-sets as defined in BPEL and is quite powerful:  here, correlation between E1-E2 is not using same message elements as Correlation between E1-E3 )

 

--------------------------------

...

<Edge from="start0" to="PurchaseOrderRequestAndConfirm1" label="true">
    <condition>
      <event name="E1" >tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/PurchaseOrderRequest</event>
      <correlation name="C0">tamie:content/wsi:message/@conversation</correlation>
      <correlation name="C1">tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/PurchaseOrderRequest/ApplicationArea/Sender/LogicalID</correlation>
    </condition>
  </Edge>

 

  <Edge from="PurchaseOrderRequestAndConfirm1" to="CancelOrderActivity1" label="PartialPurchaseOrderResponse and success">
    <condition>
      <event name="E2" >tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/PurchaseOrderResponse//ConfirmationCode['partial']</event>
      <correlation name="C1">tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/PurchaseOrderRequest/ApplicationArea/Receiver/LogicalID</correlation>
    </condition>
  </Edge>

 

  <Edge from="PurchaseOrderRequestAndConfirm1" to="Failure0" label="AnyProtocolFailure">
    <condition>
      <event name="E3" >tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/s:Fault</event>
      <correlation name="C0">tamie:content/wsi:message/@conversation</correlation>
    </condition>
  </Edge>
...

--------------------------------

 

-jacques