Patterns

This section describes how the original control-flow patterns are realised in YAWL. The solutions are grouped as follows:

 

Patterns: Basic Control Flow

Sequence

Task B follows task A.

Parallel Split

Task B, task C and task D are executed in parallel after task A. 

Synchronisation

After the execution of task B, task C, and task D, task E can be executed.

Exclusive Choice

A choice is made to execute either task B, task C or task D after execution of task A. Note that such a choice typically involves predicates specified for the various arcs. Currently such conditions are specified in XPath.

Simple Merge

Task A will be started when any one of the tasks B, C or D completes. This solution is identical to the solution for the Multiple Merge. This pattern though makes a context assumption: there is no parallelism preceding task A.

 

Patterns: Advanced Branching and Synchronisation

Multiple Choice

Task B, task C, task D or any combination thereof is executed after task A. Note that such a choice typically involves predicates for the various arcs. Currently such conditions are specified in XPath.

Synchronising Merge

Task A can execute when at least one of the tasks B, C, or D has completed and there is no possibility of another incoming branch becoming active in the foreseeable future, given the current state of the workflow. Note that this solution in YAWL does not impose any restrictions on the corresponding graph (e.g., it doesn't assume the existence of a corresponding multichoice).

Multiple Merge

See the solution for Simple Merge.

Discriminator

There are two different solutions for this.

The first thread that completes, triggers A and leads to cancellation of the other threads.

When t threads are completed, or if the number of threads is less than t when all threads are completed, task A can be initiated. Any remaining threads of task B are cancelled. This provides a solution to the n-out-of-m join. Note: the original pattern description did not prescribe cancellation of the "other threads".

 

Patterns: Structural

Arbitrary Cycles

YAWL does not impose any restrictions on cycles. A structure like the one pictured below is acceptable in YAWL.

Implicit Termination

This is the only control flow pattern not supported in YAWL. This choice was made on purpose to force designers to think carefully about workflow termination. In general it is very easy to achieve through; just connect all final tasks to an or-join which then acts as the single termination point.

Note, this solution does not always work. E.g., in case of preceding or-joins, or multiple executions of any final task.

 

Patterns: Multiple Instances

Multiple Instances Without Synchronization

Tasks B and C are executed in parallel after task A. Task B is a multiple instance task of which between n and m instances will be created. Note that there is no synchronization between instances of B and C.

Multiple Instances With a Priori Design Time Knowledge

After task A, n instances of task B are created. When all such created instances are completed, task C can start.

Multiple Instances With a Priori Run Time Knowledge

Same solution as Multiple Instances With a Priori Design Time Knowledge except that n is replaced by XQuery expressions. These expressions are evaluated at run time to help determine how many instances of task B are to be created.

Multiple Instances Without a Priori Run Time Knowledge

After completion of task A, the XQueries xq 1 and xq 2 are evaluated to help determine the number of instances to be created of task B. The 'd' indicates that new instances may be created dynamically (to a maximum of the value of xq 2).

Note that synchronization of all created threads takes place before execution of task C which is not prescribed by the original pattern. To avoid this, a similar solution as described in Multiple Instances Without Synchronization may be used.

 

Patterns: State-Based

Deferred Choice

After task A, both tasks B and C are enabled. When one of them is selected for execution, the other one is disabled.

Interleaved Parallel Routing

Given that YAWL is based on Petri nets, the idea of a mutex place can be used as presented in the patterns website.

None of the tasks A, B, C, or D are executed in parallel with any of the others. In addition, the execution of task B has to await completion of the execution of task A, and the execution of task D has to await completion of the execution of task C.

Milestone

As with Interleaved Parallel Routing, here also the fact that YAWL is based on Petri nets can be exploited and the idea described in the patterns website used.

Task C can only be executed after completion of task D and task A, and before execution of task B.

 

Patterns: Cancellation

Cancel Activity & Cancel Case

Execution of task B means cancellation of task A. In fact, any region can be chosen for cancellation so cancellation sets allow for cancellation of a single task, a whole case, and anything in between.