In version 1.0 of BPEL2oWFN the following Petri net patterns are implemented:
The Petri net semantics for BPEL4WS from Christian Stahl (Humboldt-Universität zu Berlin) published in [Sta04].
Feature complete semantics covering both positive control flow with event handling and negative control flow (fault and compensation handling).
We tried to stick as close to the Petri net patterns of [Sta05] as possible. However, the implemented patterns in the pattern database sometimes differ to the given patterns due to discovery of bugs or implementation decisions. In this subsection we sum up these changes to help you understand the generated Petri net model.
Furthermore, all failed places of the activities were removed. In the original Petri net semantics, all faults of a scope were collected on the fault_in of the stop-pattern and then classified as being the first fault of the scope, a following fault, a fault from the fault handler, a fault from the compensation handler, or a fault from a child scope. In our implementation, new places (fh_fault_in and ch_fault_in) were introduced and each activity throws its faults to the “correct” place automatically.
To ensure that at most one error can occur (i.e. at most one token is produced on any fault place) the fault places are guarded by state places: To throw a fault from an activity enclosed in a scope, the state of that scope has to be Active. The first thrown fault changes the state to !Active thus preventing more faults to occur. The places fh_fault_in and ch_fault_in, resp. are guarded by !FHFaulted/FHFaulted and !CHFaulted/CHFaulted, resp.
Moreover, the generated Petri nets have less nodes than those generated by BPEL2PN [SHS05] since an unfolding of the reset arcs in not necessary any more.
Beside performance (e.g. only 1 bit is needed to store the marking of a place) and compatibility issues (e.g. 1-safety is a prerequisite to use the Model Checking Kit [MCK]), features not supported by the Petri net semantics can be discovered since the generated net will most likely violate 1-safety when an unsupported BPEL feature is used. If, for example, a scope is enclosed in a while loop (which would model instantiation which is not supported by the Petri net semantics Limitations of the semantics), the state places of that scope would not be 1-safe.
The assign activities are sufficiently short-lived that they are allowed to complete rather than being interrupted when termination is forced.
This change fixes a bug in the Petri net semantics.
In future versions of BPEL2oWFN these found deadlocks shall be mapped back into the BPEL code to highlight the “unreasonable” activities (i.e. a cycle-closing link).