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.
- Fault model. At most one error can occur in the positive
control flow of each scope or process. Yet this confines the
possible runs of the process it is only a little change of the
semantics, since — according to the specification — only the
first fault is handled anyway. While further faults occurring before
the positive control flow is stopped are ignored in the original
semantics of [Sta05] (in fact, the faults are collected on place
fault_in and then consumed by a reset arc) they are prevented
in the implemented semantics. In our model, exactly the first
occurring fault is handled, whereas in [Sta05] one fault is chosen
non-deterministically.
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.
- Standard faults. The “throw-fault” and “stop” transitions
are generated using parametrized functions. With the command-line parameter
--parameter=nostandardfaults all BPEL standard faults
that can occur in the activites (i.e. all faults except user-defined faults
in a throw activity or join failures) are suppressed. The generated models
have a smaller state space and allow the analysis for controllability
which is impossible without the assumption that messages can always be
sent faultlessly.
In order not to suppress standard faults at all, the command-line parameter
--parameter=nofhfaults can be used to allow standard faults outside
fault handlers, i.e. to create models that allow the occurrence of one
standard fault in each scope yet disallow to occurrence of further faults.
- 1-safety. The new modeling of the fault management yields
to 1-safe Petri nets (i.e. any reachable state of the Petri net
model puts at most one token on each place of the net).
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.
- Assign activity. All copy branches of an assign activity
are modeled in a single pattern (i.e. Fig. 6 and Fig. 7 are merged).
Furthermore, when an error (outside that activity) occurs, an active
assign-activity is not stopped until all copy branches have
finished. This is described in [ACD^+03] as:
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.
- While activity. Since the original semantics does not support
instances of the BPEL process, while activities were poorly supported and
usually produced non 1-safe Petri nets or deadlocks as links embedded in
the while activity were evaluated incorrectly. In the implementation the
while activity is acyclic: the embedded activity is now executed at most
once (whether or not it is executed is decided non-deterministically).
The “original” behavior can be restored with the command-line parameter
--parameter=cyclicwhile.
- Event handlers. There is one pattern for both alarm and
message event handlers (i.e. Fig. 29 and Fig. 30 are merged). When
no event handler is specified, an “implicit” event handler is
installed which is just a stub and does not change the semantics. The
message event handlers are acyclic by default to create acyclic Petri net
models. However, the “original” behavior can be restored with the
command-line parameter --parameter=cycliceh.
- Deadlocks. A transition named 1.internal.finalloop
can be added to livelock the process upon completion using the command-line
parameter --parameter=finalloop. This leads to
deadlock-free Petri nets in case of processes with “reasonable”
control flow and helps to find unwanted deadlocks occurring due
wrong modeling. If, for example, the links of a process model are
cyclic the generated Petri net will deadlock.
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).
- Unfoldings of high-level places. Due to the abstraction (high-level to
low-level) of the patterns some places were unfolded: the place
compScope of Fig. 42–44 usually holding a token with a name
of a scope is unfolded to compScope.scopename and only
merged with the ch_in-place of that respective scope. In all
other cases the places are “converted” to low-level places so the
generated model completely abstracts from data.
- Link semantics. The generated Petri net model always
generates negLink places for structured activities
independently of the presence of links. Anyway, the semantics is not
changed since the resulting subnets are dead in this case.
- Correlation sets. Correlation sets are not implemented and
are simply ignored during parsing.