Semantics, Verification, and Implementation of Workflows ... - YAWL

Chapter 1. Introduction
There is a trade-off between expressive power and ease of verification. One of
the drawbacks of an expressive language like YAWL is that it makes it difficult
to determine the correctness of workflow specifications modelled in the language.
There exists a body of work concerning the verification of workflow specifications
based on Petri nets [Aal97, Aal98b, AH00, Ver04, DA04]. Unfortunately, these
results are not transferable to situations where languages are involved that use
concepts either not easily expressed in terms of Petri nets such as cancellation
regions and OR-join. These concepts are examined in more depth in the next
two sections.
1.4 Cancellation regions
Cancellation occurs frequently in business scenarios and hence, in workflow modelling.
Cancellation captures the interference of an activity in the execution of
others in certain circumstances. Cancellation can be triggered by either a customer
request (e.g., a customer wishes to withdraw a credit card application) or
by exceptions (e.g., an order cannot be processed due to insufficient stock level).
In general, cancellation results in one of two outcomes: disabling some scheduled
activities or stopping currently running activities.
Sometimes, cancellation affects only a selective part of a workflow and other
activities can continue after performing a cancellation action. When cancellation
only involves a single activity, this behaviour is captured by the “cancel activity”
workflow pattern [AHKB03, AH02, Kie03]. In an evaluation reported by Kiepuszewski
[Kie03], it is shown that this pattern is not supported by the following
commercial workflow management systems: Visual WorkFlo, Verve Workflow,
MQSeries Workflow, Forte Conductor, HP Change Engine, Fujitsu I-Flow and
SAP R/3 Workflow. When cancellation affects the entire workflow case, it stops
the execution of the workflow and the process is terminated. This behaviour is
captured by the “cancel case” pattern [AHKB03, AH02, Kie03]. A number of
workflow systems support this pattern using either a terminate activity, a dedicated
final activity or an abort function. There are also serval standards and
tools that has such a concept (e.g., UML activity diagrams, Staffware, BPMN,
etc).
As cancellation occurs naturally in business scenarios, comprehensive support
in a workflow language is desirable. The notions of cancel activity and cancel case
can be generalised to the notion of cancellation region whereby an arbitrary region
of a workflow specification can be subjected to a cancellation action. It should
be noted that the introduction of arbitrary cancellation regions complicates the
notion of reachability whereby one wishes to determine whether a certain future
state of the workflow can be attained from a certain other state. In fact, as will
be seen later on, this notion becomes undecidable. The complicating factor is
that due to concurrency issues, the cancellation action may or may not result in
cancelling certain activities, i.e., the process may be in a state before or after that
part that is cancelled. It is also clear that the introduction of cancellation regions
may lead to deadlocks in some specifications in some scenarios. New techniques
are required to enable design time detection of verification problems in workflows
with cancellation regions (e.g., deadlocks, improper completion).
PhD Thesis – c○ 2006 M.T.K Wynn – Page 3