Support Matrix Control Workflow Patterns in JBoss BPM Suite

In another installment of the JBoss BPM Suite Tips & Tricks series we will be helping you to understand the Control Workflow Patterns support that JBoss BPM Suite provides.

This article will outline the the basic control flow patterns as defined by vdAtHKB03. We will then analyze what patterns have limited support due to restrictions imposed by the BPMN2 process specification as detailed in BPM-06-22.

We will cover the complete set of 20 control flow patterns, starting with the five basic control flow patterns and finishing with the fifteen advanced branching and synchronization patterns.

Patterns

In the original research paper the authors cover five (5) basic control flow patterns:

1. Sequence - an activity in a workfow process is enabled after the completion of a preceding activity in the same process.
2. Parallel Split - point in the workflow process where a single thread of control splits into multiple threads of control which can be executed in parallel, thus allowing activities to be executed simultaneously or in any order.
3. Synchronization - point in the workfow process where multiple parallel subprocesses/activities converge into one single thread of control, thus synchronizing multiple threads.
4. Exclusive Choice - point in the workflow process where, based on a decision or workflow control data, one of several branches is chosen.
5. Simple Merge - point in the workflow where two or more alternative branches come together without synchronization. It is an assumption of this pattern that none of the alternative branches are ever executed in parallel.

After these five patterns the authors continue on to cover fifteen (15) advanced branching and synchronization patterns:

1. Mulit-choice - point in the workflow process where, based on a decision or workflow control data, a number of branches are chosen.
2. Synchronizing Merge - point in the workflow process where multiple paths converge into one single thread. If more than one path is taken, synchronization of the active threads needs to take place. If only one path is taken, the alternative branches should reconverge without synchronization. It is an assumption of this pattern that a branch that has already been activated, cannot be activated again while the merge is still waiting for other branches to complete.
3. Multi-merge - point in a workflow process where two or more branches reconverge without synchronization. If more than one branch gets activated, possibly concurrently, the activity following the merge is started for every activation of every incoming branch.
4. Discriminator - discriminator is a point in a workflow process that waits for one of the incoming branches to complete before activating the subsequent activity. From that moment on it waits for all remaining branches to complete and "ignores" them. Once all incoming branches have been triggered, it resets itself so that it can be triggered again (which is important otherwise it could not really be used in the context of a loop).
5. Arbitrary Cycles - point in a workflow process where one or more activities can be done repeatedly.
6. Implicit Termination - given subprocess should be terminated when there is nothing else to be done. In other words, there are no active activities in the workflow and no other activity can be made active (and at the same time the workflow is not in deadlock).
7. Multiple Instances Without Synchronization - Within the context of a single case (i.e., workflow instance) multiple instances of an activity can be created, i.e., there is a facility to spawn o new threads of control. Each of these threads of control is independent of other threads. Moreover, there is no need to synchronize these threads.
8. Multiple Instances With a Priori Design Time Knowledge - For one process instance an activity is enabled multiple times. The number of instances of a given activity for a given process instance is known at design time. Once all instances are completed some other activity needs to be started.
9. Multiple Instances With a Priori Runtime Knowledge - For one case an activity is enabled multiple times. The number of instances of a given activity for a given case varies and may depend on characteristics of the case or availability of resources, but is known at some stage during runtime, before the instances of that activity have to be created. Once all instances are completed some other activity needs to be started.
10. Multiple Instances Without a Priori Runtime Knowledge - For one case an activity is enabled multiple times. The number of instances of a given activity for a given case is not known during design time, nor is it known at any stage during runtime, before the instances of that activity have to be created. Once all instances are completed some other activity needs to be started. The difference with Pattern 9 is that even while some of the instances are being executed or already completed, new ones can be created.
11. Deferred Choice - point in the workflow process where one of several branches is chosen. In contrast to the XOR-split, the choice is not made explicitly (e.g. based on data or a decision) but several alternatives are offered to the environment. However, in contrast to the AND-split, only one of the alternatives is executed. This means that once the environment activates one of the branches the other alternative branches are withdrawn. It is important to note that the choice is delayed until the processing in one of the alternative branches is actually started, i.e. the moment of choice is as late as possible.
12. Interleaved Parallel Routing - set of activities is executed in an arbitrary order: Each activity in the set is executed, the order is decided at run-time, and no two activities are executed at the same moment (i.e. no two activities are active for the same workflow instance at the same time).
13. Milestone - enabling of an activity depends on the case being in a speci ed state, i.e. the activity is only enabled if a certain milestone has been reached which did not expire yet. Consider three activities named A, B, and C. Activity A is only enabled if activity B has been executed and C has not been executed yet, i.e. A is not enabled before the execution of B and A is not enabled after the execution of C.
14. Cancel Activity - An enabled activity is disabled, i.e. a thread waiting for the execution of an activity is removed.
15. Cancel Case - A case, i.e. workflow instance, is removed completely (i.e., even if parts of the process are instantiated multiple times, all descendants are removed).

Now we can focus on JBoss BPM Suite and evaluate what it is capable of supporting and to what degree.

JBoss BPM Suite

Looking at the product for coverage of these basic control flow patterns, we can put together the following matrix. If JBoss BPM Suite directly supports the pattern through one of its constructs, it is rated +. If the pattern is not directly supported, it is rated +/-. Any solution which results in spaghetti diagrams or coding, is considered as giving no direct support and is rated -.


The JBoss BPM Suite product overview matrix showing the potential support for the advanced branching and synchronization patterns is as follows.


As you might have noticed, JBoss BPM Suite is able to support almost all of the control workflow patterns as outlined by vdAtHKB03. Where there is limited support for a pattern is only due to the adherence to the BPMN standard as explained in  BPM-06-22. 

We hope this overview outlines the potential JBoss BPM Suite has for supporting control workflow patterns.

In a follow up articles we will provide examples projects to support these claims, so stay tuned.