jBPM Evaluation Results

Evaluation results for jBPM version 3.1.4 against the workflow control-flow patterns

Pattern

Rating

Motivation
Sequence + jBPM uses a transition between two task nodes for capturing a sequence
Parallel Split +

jBPM supports parallel split through:
i) the Fork Node construct, which splits a tread to multiple treads running in parallel
ii) by defining the tasks to be run in parallel within the same Task Node.
Synchronization + jBPM supports synchronization through:
i) the Join Node construct to which threads running in parallel converges
ii) if the tasks to be synchronized are defined within the same Task Node, the node itself will act as synchronizer of its tasks.
Exclusive Choice + jBPM implements exclusive choice through the Decision construct

Simple Merge

+ jBPM implements simple merge through a Task Node to which the split (earlier in the flow) treads, one of which is executed, converges.
Multi-Choice - jBPM does not directly support multi choice. The behavior can be implemented through a Node type Node, where the semantics of the pattern have to be coded in Java
Structured Synchronizing Merge - jBPM does not support it, as it does not support multi choice, which is a prerequisite for this pattern.
Multi-Merge + jBPM implements multiple merge through a Task Node to which the split (earlier in the flow) treads, possibly running in parallel, converges.
Structured Discriminator - jBPM does not support this pattern
Arbitrary Cycles + jBPM allows definitions of arbitrary cycles.
Implicit Termination + jBPM supports Implicit Termination. A process may have multiple End States. A process instance completes when there is not any work item left to be done. jBPM notifies the user executing the last work item about the completion of a process.
Multiple Instances without Synchronization + jBPM supports this pattern as new instances of tasks can be spawned off through the use of a loop
Multiple Instances with a Priori Design-Time Knowledge - jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language
Multiple Instances with a Priori Run-Time Knowledge - jBPM does not support this pattern.
Multiple Instances without a Priori Run-Time Knowledge - jBPM does not support this pattern.
Deferred Choice + jBPM support this pattern by allowing more than one transition to leave a Task Node. At run-time one of these alternative transitions needs to be selected by the user.
Interleaved Parallel Routing - jBPM does not support this pattern.
Milestone - jBPM does not support this pattern.
Cancel Activity +

In jBPM a task can be forcibly ended using the Monitoring mode at runtime. A forcibly ended task (through the "End" command) remains in the execution log.
Cancel Case - In jBPM a process can be forcibly ended at runtime using the Monitoring mode. A forcibly ended process (through the "Delete" command) is removed from the execution log. Therefore the Cancel Case pattern is not considered to be supported.
Structured Loop - jBPM can achieve the behavior of structured loops, but any dedicated construct for this is missing.
Recursion - jBPM does not support recursion.
Transient Trigger + jBPM supports transient triggers through the notion of State. When a process instance reaches a state on its execution path, it awaits for a signal in order to leave the state and continue execution.
The concept of Timer is also present in jPDL. However, currently timers does not work in the engine when XML process definitions have been deployed to the engine and instances of them initiated from the web console interface.

Persistent Trigger

 - jBPM does not support this pattern.
Cancel Region - jBPM does not support this pattern.
Cancel Multiple Instance Activity - jBPM does not support this pattern.
Complete Multiple Instance Activity - jBPM does not support this pattern.
Blocking Discriminator - jBPM does not support this pattern.
Cancelling Discriminator - jBPM does not support this pattern.
Structured Partial Join - jBPM does not support this pattern.
Blocking Partial Join - jBPM does not support this pattern.
Cancelling Partial Join - jBPM does not support this pattern.
Generalised AND-Join + jBPM - The semantics of the Join node captures the captures the semantics of the Generalized AND-Join pattern.
Static Partial Join for Multiple Instances - jBPM does not support this pattern.
Cancelling Partial Join for Multiple Instances - jBPM does not support this pattern.
Dynamic Partial Join for Multiple Instances - jBPM does not support this pattern, which is a variant of the Multiple Instances without a priori run-time Knowledge pattern.
Local Synchronizing Merge - jBPM does not support this pattern.
General Synchronizing Merge - jBPM does not support this pattern
Critical Section - jBPM does not support this pattern.
Interleaved Routing - jBPM does not support this pattern.
Thread Merge +/- In jBPM the behavior of this pattern can be achieved through programmatic extensions by defining a new Node behavior. (According to the evaluation criteria of the pattern, this gives a +/- ranking).
Thread Split +/- In jBPM the behavior of this pattern can be achieved through programmatic extensions by defining a new Node behavior. (According to the evaluation criteria of the pattern, this gives a +/- ranking).
Explicit Termination - jBPM does not support this pattern. A process instance completes when there is not any work item left for execution.

Evaluation results for jBPM version 3.1.4 against the workflow data patterns

Pattern

Rating

Motivation
Task Data +/- In jBPM due to the fact that task variables are mapped to process variables on a one-one basis and the inherent difficulty of defining task variables that do not strictly correspond to existing process variables, the Task Data pattern is not considered to be supported. The Node construct provides the possibility to introduce custom code. Local task data can then be defined and used in such a code. Therefore the support for this pattern is ranked as partial.
Block Data -

jBPM does not support block data.
- The notion of Super State in jPDL is intended for grouping nodes into logical units and provides hence the semantics of blocks. However, it is not currently possible to in the GPD define the components composing a Super State.
- The notion of Process State in jPDL is introduced for facilitating the invocation of sub-processes which are described in terms of distinct process fragments to the main process definition. However, the use of this construct is problematic when the process definition is done through the GPD. Hence, block data is not yet considered to be supported.

Scope Data - jBPM does not support scope data. The Task Node construct can accommodate several Tasks and can potentially be considered as a partial implementation of the scope concept. However, no data elements can be defined for a Task Node.
Multiple Instance Data - jBPM lacks any notion of multiple instance tasks hence multiple instances data is not supported.
Case Data + In jBPM the common approach to characterising data elements is via process variables.
Folder Data - jBPM does not support folder data.
Workflow Data - jBPM does not support global data.
Environment Data +/- jBPM does not directly support environment data. Access to environment data is achieved through programming in Java, via Actions or Nodes.
Task to Task + jBPM supports this pattern through global shared data.
Block Task to SubWorkflow Decomposition - jBPM does not support this pattern as any attempt for process decomposition defined through the GPD failed.
SubWorkflow Decomposition to Block Task - jBPM does not support this pattern as any attempt for process decomposition defined through the GPD failed.
To Multiple Instance Task - jBPM does not support this pattern as it lacks a notion for multiple instances tasks.
From Multiple Instance Task - jBPM does not support this pattern as it lacks a notion for multiple instances tasks.
Case to Case +/- jBPM partially supports case-to-case interaction, as such interaction is indirectly achieved through programmatic interaction with an external database, for example, by associating an action with a transition. In this way the general form of case-to-case communication, where a case communicates to all the other cases is supported.
Task to Environment - Push-Oriented +/- External data interaction in jBPM is realized at task (and transition) level, rather than at process level. The Data Interaction -- Task to Environment - Push oriented is simplest realized through Actions (i.e. by coding an ActionHandler java class), which are defined on transitions or the entrance or the leave of nodes. Due to the java coding which is needed in order to get the data interaction working, the support for this pattern is considered as partial.
Environment to Task - Pull-Oriented +/- External data interaction in jBPM is realized at task (and transition) level. Data Interaction -- Environment to Task -- Pull oriented is implemented through Nodes which can stop and await the receipt of the data they are pulling from the external source. Due to the java coding which is needed in order to get the data interaction working, the support for this pattern is considered as partial.
Environment to Task - Push-Oriented - jBPM does not support this pattern.
Task to Environment - Pull-Oriented - jBPM does not support this pattern.
Case to Environment - Push-Oriented - jBPM does not support this pattern.
Environment to Case - Pull-Oriented - jBPM does not support this pattern.
Environment to Case - Push-Oriented - jBPM does not support this pattern.
Case to Environment - Pull-Oriented - jBPM does not support this pattern.

Workflow to Environment - Push-Oriented

 - jBPM does not support this pattern.
Environment to Workflow - Pull-Oriented - jBPM does not support this pattern.
Environment to Workflow - Push-Oriented - jBPM does not support this pattern.
Workflow to Environment - Pull-Oriented - jBPM does not support this pattern.
Data Transfer by Value - Incoming - jBPM does not support this pattern.
Data Transfer by Value - Outgoing - jBPM does not support this pattern.
Data Transfer - Copy In/Copy Out + Data is transferred in jBPM by using a Copy in/Copy out strategy. When dealing with concurrent tasks, this implies that at creation every work item receives a copy of the data values in the global process variables. Any updates to these values by a concurrent work item remains invisible outside that work item. At completion the values for each work item are copied back (if so specified) to the global process variables, overwriting the existing values for these variables. This means that the work item to comlete last will be the last one to copy its value back to the process variables. To avoid problems with lost updates, a process designer needs to be careful with granting write access to variables for tasks that run in parallel and update global data.
Data Transfer by Reference - Unlocked - jBPM does not support this pattern.
Data Transfer by Reference - With Lock - jBPM does not support this pattern.
Data Transformation - Input + jBPM supports data transformation on input data by allowing for the specification of scripts that can transform data elements at the initiation of a task node (which is specified by the event type "node-enter"). When a task-node contains a single task, the node-enter scripts provide support for the data transformation on input data pattern.
(Theoretically, jPDL also supports scripts at the creation, start, assignment and end of a task, but this failed as the scripts we defined for tasks did not execute.)
Data Transformation - Output + jBPM supports data transformation on output data by allowing for the specification of scripts that can transform data elements at the completion of a task node (which is specified by the event type "node-leave"). When a task-node contains a single task, the node-leave scripts provide support for the data transformation on output data pattern.
Task Precondition - Data Existence - jBPM does not support this pattern. By default a task-node is enabled when one of its incoming transitions propagate a token. Consequently, defining preconditions on a tak-node can be considered as a form of restricting the tokens passing through its incoming transitions. Actions associated with transitions can not be used in this way as actions cannot influence the control-flow of a process. Furthermore, any "guards" controlling the tokens passing through a transition (similar to those supported in UML activity diagrams) are deliberately not included in jPDL (according to "Why does jPDL lack a notion of a guard condition on every transition? on wiki.jboss.org/wiki/Wiki.jsp\?page=Jbpm3FAQ).
Task Precondition - Data Value - jBPM does not support this pattern. See the motivation for RP34.
Task Postcondition - Data Existence - jBPM does not support this pattern. (This pattern is intended to be supported through the Required attribute for variables in jPDL. However, whilst it is possible to define a variable as required, it was found that not providing a value for that variable did not prevent the user from registering the task as completed)
Task Postconditon - Data Value - jBPM does not support this pattern.
Event-Based Task Trigger - jBPM does not support this pattern. The node State can only be used for receiving signals as triggers, without any data attached to the signals.
Data-Based Task Trigger - jBPM does not currently support data-based task triggers (as stated on www.jboss.com/index.html?module=bb&op=viewtopic&t=102283)
Data-Based Routing +/- jBPM supports the data-based routing pattern through the Decision Node construct. The support is rated as partial as there is no support for the multi-choice variant of the pattern.

Evaluation results for jBPM version 3.1.4 against the workflow resource patterns

Pattern

Rating

Motivation
Direct Allocation + jBPM supports this pattern and allows a task to be assigned to a user (through <assignment expression="user(username)"> for a task).
Role-Based Allocation - jBPM does not support this pattern currently. jPDL has the primitives groups and members, but currently a work item which is distributed to a group with several members is only stored in the database from where it can not be "pulled out" and executed by anyone.
Deferred Allocation + jBPM supports deferred allocation. It is implemented using variables which receive their values at runtime before the commencement of the relevant task.
Authorisation - jBPM does not support this pattern.

Seperation of Duties

 - jBPM does not support this pattern.
Case Handling - jBPM does not support this pattern.
Retain Familiar + jBPM supports this pattern through <assignment expression "previous"> for a task.
Capability Based Allocation - jBPM does not support this pattern.
History Based Allocation - jBPM does not support this pattern.
Organisational Allocation - jBPM does not support this pattern currently. jPDL has a primitive role. An assignment of a task can be specified as <assignment expression = "group(employees) --> role(programmer)">. However, currently a work item which is distributed to a role with several users playing it, gets only stored in the database from where it can not be "pulled out" and executed by a user playing this role.
Automatic Execution + jBPM supports this pattern through the notion of Nodes, where any customized behaviour can be defined.
Distribution by Offer - Single Resource - jBPM does not support this pattern.
Distribution by Offer - Multiple Resources - jBPM does not support this pattern.
(In a later tested release (i.e. 3.2.1), jBPM seems to be preparing support for distribution by offer to multiple resources, however such support is not yet available.)
Distribution by Allocation - Single Resource + jBPM currently supports distribution by allocation to a single resource.
Random Allocation - jBPM does not support this pattern. The pattern is only relevant when a system selects a resource from a number of possible candidates which does not occur in jBPM.
Round Robin Allocation - jBPM does not support this pattern. The pattern is only relevant when a system selects a resource from a number of possible candidates which does not occur in jBPM.
Shortest Queue - jBPM does not support this pattern. The pattern is only relevant when a system selects a resource from a number of possible candidates which does not occur in jBPM.
Early Distribution - Enhydra Shark does not support this pattern. It only supports offering and not allocation of work items.
Distribution on Enablement + In jBPM when a work item is created, it is immediately distributed.
Late Distribution - jBPM does not support this pattern.
Resource-Initiated Allocation - jBPM does not support this pattern.
Resource-Initated Execution - Allocated Work Item + In jBPM, a work item that is allocated to a resource can be started by the resource selecting the work item from their work list.
Resource-Initiated Execution - Offered Work Item - jBPM does not support this pattern.

System Determined Work Queue Content

 - jBPM does not support this pattern.
Resource-Determined Work Queue Content - jBPM does not support this pattern.
Selection Autonomy + jBPM supports this pattern.
Delegation - jBPM does not support this pattern.
Escalation - jBPM does not support this pattern.
Deallocation - jBPM does not support this pattern.
Stateful Reallocation - jBPM does not support this pattern.
Stateless Reallocation - jBPM does not support this pattern.
Suspension/Resumption + In jBPM a work item can be suspended by selecting one of "Save" and "Cancel" menus for stateful or stateless suspension.
Skip - jBPM does not support this pattern. The <cursor> construct with its "skip" command does not provide support for this pattern. Either is "skip" evaluated after the work item during which it was commanded gets completed (which is registered as successfully completed in the log), or when "skip" refers to the next-following task(s) in the flow, any work item(s) for this(these) task(s) never gets created.
Redo - jBPM does not support this pattern.
Pre-Do - jBPM does not support this pattern.
Commencement on Creation - jBPM does not support this pattern, as a work item can not be started by the system. A resource alone can initiate the execution of a work item.
Commencement on Allocation - jBPM does not support this pattern, as a work item can not be started by the system. A resource alone can initiate the execution of a work item.
Piled Execution - jBPM does not support this pattern, as a work item can not be started by the system. A resource alone can initiate the execution of a work item.
Chained Execution - jBPM does not support this pattern, as a work item can not be started by the system. A resource alone can initiate the execution of a work item.
Configurable Unallocated Work Item Visibility - jBPM does not support this pattern.
Configurable Allocated Work Item Visibility - jBPM does not support this pattern.
Simultaneous Execution - jBPM does not support this pattern.
Additional Resources - jBPM does not support this pattern.