In this section we give our correctness criteria for the BPEL semantics properties given in Section : 2.2. The correctness is based on describing the semantics properties in the form of LTL properties. These properties can be either verified on isolated patterns or on instances of the FIACRE patterns. Here we follow the second technique and verify the correctness properties directly on instances of the use case’s patterns (see Chapter Use Case). The satisfaction of the properties is a correctness proof of the preservation of the BPEL semantics by the FIACRE patterns.
2.6.1 Control Correctness
In the first category of properties, we consider the BPEL constructs while ignoring the links and the possibility of faults. This means that the order of execution of an activity depends only on the control flow and not on its incoming links.
Sequence The correctness of the start of the sequence activity may be given as follows :
¬startact1 W startsequence Sequence Start
That is, the first activity of the sequence cannot start unless the whole sequence is started. Here we use the weak until operator W in order to say that startsequence may not occur. We could have also generalized this
property as ¬startacti W f inishacti−1. But this property is trivially verified in our patterns since startacti and f inishacti−1 are the same event.
A sequence ends when its last activity does. For n designating the last activity of the sequence, the end of the sequnce can be written as :
¬f inishsequence W f inishactn Sequence Finish 1
That is, the whole sequence cannot finish unless the last activity of the sequence is finished.
Another type of formulas can be tested also, which is the reverse of the previous formula. The end of the last activity of the sequence eventually leads to the end of the sequence in case no forced termination occurs.
(f inishactn ⇒ ♦(f inishsequence∨stpd)) Sequence Finish 2
Flow A flow starts when all its embedded activities do. Formally, for i∈ 1..NbActFlow the correctness of the start of the flow can be written in the following way :
¬startacti W startf low Flow Start
That is, the activities of the flow cannot start before the flow does. The end of the flow may be written as follows :
^
i
¬f inishf low W f inishacti Flow Finish
2.6.2 Links Semantics
In this category, we show how we analyze the semantics of the BPEL links. An activity starts if the status of all its links have been received. Since the links are represented by a decrementing counter in FIACRE, this is checked by the following property :
(start⇒act_counter=0) Incoming Links
This means that the start of an activity can only be made if its incoming links counter equals 0.
Concerning the setting of the outgoing links, the property that an ac- tivity cannot finish without setting its outgoing links (in case they are present) is trivially satisfied by our patterns since this is done in the same transition. Blocking (resp. firing) this transition means blocking (resp. fir- ing) the finish signal and the decrementing of the counter corresponding to the outgoing links. Here remind the reader that in case of fault thrown while setting the outgoing links, a finish event is not signaled.
Sequence With Links Now considering the links, the Sequence and the Flow properties are adapted accordingly. Actually in the following prop- erties we take into account both the links and the faults. For example, the properties of the Sequence become the following :
(startsequence ⇒ ♦(counter_act1=0⇒ ♦(startact1∨f a))) Sequence Links That is, if the first activity of the sequence has received all its links and no faults (fa) are generated then the start of sequence implies the start of the first activity of the sequence.
2.6.3 Weak Termination
Being a weak termination, the stop demand is not considered instantly. This means that the activities have the choice whether to take the stop de- mand into consideration by transiting back to the init state or to remain in their active states. This can be represented by :
(stopscope ⇒ ♦stpdscope) Weak Termination
That is, if a stop demand is signaled, the scope will eventually do its stpd event. We note here that this characterization of Weak Termination of BPEL is different than the Weak Until Semantics in LTL, since weak ter- mination usually means that it may never happen.
2.6.4 Strong Termination
In the strong termination we want to guarantee that whenever a termi- nation is demanded it will be taken immediately into consideration. For- mally the strong termination can be written as follows :
(stopscope ⇒ (¬
_
e∈eventscope
That is, whenever a stop is demanded, none of the events of the scope may occur before the occurrence of the stpd event.
2.6.5 Hierarchical Termination
Whenever a scope is asked to stop, the fault handler of the scope starts by synchronizing with all the child activities nested in the scope. Once this synchronization has occurred -meaning that these activities have stopped- the fault handler controller proceeds with signaling the termination of the whole scope by synchronizing with its upper scope’s fault handler. Hence a hierarchical view of termination is respected in our implementa- tion. More formally, for i denoting the activities nested in the scope, the termination can be written in the following way :
(stop_up⇒ ♦(stpd_up∧^ i
initi)) Hierarchical Termination
That is, whenever a global stop is demanded, the scope (its fault handler) signals the stpd_up event and all the nested activities are in their initial states (where the local stpd event is available).
2.6.6 Hierarchical Fault Propagation
The fault propagation can be written in the following way :
(#not_handled⇒ ♦f ault_up) Fault Propagation
This means that in case of receiving an internal fault via the firing of the not_handled transition of the fault handler, then the fault_up event will eventually be signaled. The keyword # is used in FIACRE to give an alias to the transition. So, not_handled is the name of a fault handler transition that leads to the not_handled state after receiving a fault that cannot be handled by the fault handler.
2.6.7 Event Handlers
The enablement and the disablement of an event handler depends on the nominal execution of the scope. In the following we give their correctness criteria :
Enablement : If the scope does not contain an initial start activity, the event handler is enabled upon the starting of the scope.
(#startEH⇔#startActScope) Enablement Event1
That is, starting the scope means starting the event handler as well. startEH and startActScope are the aliases of respectively an event han- dler transition that starts the event handler and a scope transition that starts the primary activity of the scope.
Otherwise, the event handler is enabled once the inital start activity (receive) is finished :
Disablement : We give two disablement properties :
(¬f inishscopeW f inishPact) ∧ (¬f inishscope W f inishEH) Disablement Event1
That is, the scope cannot finish unless both of its primary activity and its event handler are finished.
(((f inishPact∧ ♦f inishEH) ∨ (f inishEH∧ ♦f inishPact)) ⇒ ♦(f inishscope∨f a))
That is, if the scope’s primary activity and the event handler finish in whatever order and at different instants then the whole scope eventually either finishes or a fault is thrown.
2.7
Conclusion
In this chapter, we have given the idea of the transformation from BPEL to FIACRE. This transformation is a one-to-one transformation, meaning that for each BPEL construct corresponds a FIACRE component. The transfor- mation preserves the hierarchical composition of BPEL and treats its timed features. Another important feature of the transformation is that it can be proven correct via a verification of some BPEL semantic properties on the FIACRE patterns. In the next chapter, we present our BPEL verification framework.