OpenWFE Evaluation Results

Evaluation results for OpenWFE version 1.7.3 against the workflow control-flow patterns

Pattern

Rating

Motivation
Sequence + OpenWFE implements the construct <sequence>
Parallel Split + OpenWFE implements parallel split through the construct <concurrence>
Synchronization + OpenWFE is a block structured language. The closing tag </concurrence> for a concurrence block implements synchronization.
Exclusive Choice + OpenWFE implements exclusive choice through the <case> construct, within which a number of condition-action pairs are defined. The first condition to evaluate to true will trigger its pair-action.

Simple Merge

+ OpenWFE supports Simple Merge through the closing tag </case> of the <case> construct.
Multi-Choice +/- OpenWFE does not provide a direct support for this pattern. The behavior can be achieved by a collection of it-then clauses execution concurrently, where several of the in-conditions may evaluate to true
Structured Synchronizing Merge - OpenWFE does not support it, as it does not fully support multi choice, which is a prerequisite for this pattern.
Multi-Merge - OpenWFE does not support it, due to its structured nature
Structured Discriminator + OpenWFE supports structured discriminator through the <concurrence> construct with the attribute settings count = "1" and remaining = "forget".
Arbitrary Cycles + OpenWFE supports arbitrary cycles with multiple exit points through the construct of <cursor>.
Implicit Termination + OpenWFE supports Implicit Termination. Currently, OpenWFE does not notify the user of a process instance completion but it only notes the completion of process instances in the log of execution history.
Multiple Instances without Synchronization + OpenWFE supports this pattern through a loop launching new instances of the multiple instances task as subprocesses. Setting the forget attribute to "true" ensures that synchronization over the created instances will not take place.
Multiple Instances with a Priori Design-Time Knowledge + OpenWFE implements this pattern through the <concurrent-iterator> construct. In the on-value attribute of the <concurrent-iterator> a list of constants is defined during design time. Each of the items in this list will result in the creation of a corresponding instance. The created instances will run in parallel and synchronized after completion.
Multiple Instances with a Priori Run-Time Knowledge + OpenWFE implements this pattern through the <concurrent-iterator> construct. To the on-field-value attribute of the <concurrent-iterator> a list of variables retrieved during run-time is sent. Each of the items in this list will result in the creation of a corresponding instance. The created instances will run in parallel and synchronized after completion.
Multiple Instances without a Priori Run-Time Knowledge - OpenWFE does not support this pattern. The <concurrent-iterator> construct can only be used when the number of instances to be created is known before the commencement of the multiple instance task. The repeated invocation of a sub-process within a loop with the attribute forget = "true" (which is the solution proposed in OpenWFE Specification, Chapter 7 Workflow Patterns, Pattern 15) does not synchronize the created instances and hence does not capture the full semantics of the pattern.
Deferred Choice - OpenWFE does not support this pattern.
Interleaved Parallel Routing +/- OpenWFE partially supports this pattern through the construct <interleaved>. The support is partial since any block defined within the interleaved construct, once started can not be interrupted so that other branches from the interleaved construct can be executed in between.
Milestone - OpenWFE does not support this pattern.
Cancel Activity - OpenWFE Cancellation of an activity can in practice be done by a system administrator through the command-line control program, but as this form of cancellation is rather a maintenance measure than a normal process activity, it is not considered to provide support for the cancel activity pattern.
Cancel Case +/- OpenWFE supports this pattern through the notion of <cancel-process/>. However, any subprocesses invoked and running when <cancel-process/> is reached do not get cancelled. Therefore, the support is only considered to be partial.
Cancellation of a case can in practice be done by a system admininstrator through the command-line control program, but as this form of cancellation is rather a maintainance measure than a normal process activity, it is not considered to provide support for the cancel case pattern.
Structured Loop + OpenWFE provides direct support for the Structured Loop. Both the while-do and repeat-until variants of the Structured Loop pattern are supported by the <loop> construct. Furthermore, the <iterator> construct implements the behaviour commonly associated with for-loops from classical programming languages.
Recursion + OpenWFE supports recursion through the invocation of a sub-processes, which can recursively invoke itself.
Transient Trigger + OpenWFE provides support for this pattern through the notion of <sleep until="date"/> construct.

Persistent Trigger

 - OpenWFE does not support this pattern.
Cancel Region - OpenWFE does not support this pattern.
Cancel Multiple Instance Activity - OpenWFE does not support this pattern.
Complete Multiple Instance Activity - OpenWFE does not support this pattern.
Blocking Discriminator - OpenWFE does not support this pattern.
Cancelling Discriminator + OpenWFE supports structured discriminator through the <concurrence> construct with the attribute settings count = "1" and remaining = "cancel".
Structured Partial Join + OpenWFE supports this pattern through the <concurrence> construct with the attribute settings count = "X" and remaining = "forget", where X is the number of treads to be joined.
Blocking Partial Join - OpenWFE does not support this pattern.
Cancelling Partial Join + OpenWFE supports this pattern through the <concurrence> construct with the attribute settings count = "X" and remaining = "cancel", where X is the number of treads to be joined
Generalised AND-Join - OpenWFE does not support it, due to its structured nature.
Static Partial Join for Multiple Instances + OpenWFE supports this pattern through the attribute count of the <concurrent-iterator>. Count defines the number of instances of the multiple instances task that need to complete before the synchronization is done and the flow can continue. The attribute remaining is set to "forget" so that threads remaining after the completion of the multiple instance task are not cancelled.
Cancelling Partial Join for Multiple Instances + OpenWFE supports this pattern through the attribute count of the <concurrent-iterator>. Count defines the number of instances of the multiple instances task that need to complete before the synchronization is done and the flow can continue. The attribute remaining is set to "cancel" so that not completed instances get cancelled.
Dynamic Partial Join for Multiple Instances - OpenWFE does not support this pattern.
Local Synchronizing Merge +/- OpenWFE partially supports this pattern. The scenario from the animation of the pattern is achieved through the <concurrrence> construct containing a number of if-then statements for starting the desired activities. The end of the </concurrence> will synchronize these of them which were started. In order to simulate the unstructured part of the scenario (where one of the parallel activities starts a branch that shall not be synchronized) a sub-process (containing this branch) is invoked. The attribute setting forgot = "true" in the sub-process invocation has to be done. If defines the execution of the sub-process as asynchronous which enables the continuation of the main process in parallel to the execution of its sub-process. Forcing this asynchronous execution entails the limitation that the sub-process (including all activities in it) can not later on be synchronized with any activity within the main-process.
General Synchronizing Merge - OpenWFE does not support this pattern. It is indeed possible to simulate the situation from the animation of the pattern (by extending the solution for WCP37 with a loop), but it is only a partial work-around solution limited to the situations where the loop is structured. If the pattern is included in a more complex unstructured scenario (as for instance the one shown in Figure 1.56 in Nick's thesis with the extension that also the tasks o1 and o2 are followed by a General Synchronizing Merge) the block structured OpenWFE will not be able to capture it.
Critical Section - OpenWFE does not support this pattern.
Interleaved Routing + OpenWFE supports this pattern through the construct <interleaved>.
Thread Merge - OpenWFE does not support this pattern.
Thread Split - OpenWFE does not support this pattern.
Explicit Termination - OpenWFE does not support explicit termination. If several sub-processes are invoked, the main process completes when all its sub-processes complete (not when its end </process> tag is reached).

Evaluation results for OpenWFE version 1.7.3 against the workflow data patterns

Pattern

Rating

Motivation
Task Data - OpenWFE does not support task data.
Block Data + OpenWFE supports block data through the notion of sub-processes and local variable binding (i.e. through the notion of ./varname).
Scope Data +/- OpenWFE supports scope data through the notion of filters. The use of filters for limiting access to fields rates as partial support as the filter overwrites the default privileges for the data element and as such restricts rather than extends the access rights associated with it. As the number of data elements associated with a process instance increases during its execution, the use of filters for restricting data flow becomes complex.
Multiple Instance Data + OpenWFE supports multiple instance data visibility by the attribute on-value (or on-field-value) specified for a <concurrent-iterator>. It also supports shared implementation of tasks through sub-processes.
Case Data + In OpenWFE, all data elements are globally accessible throughout a process instance and, once defined, all fields are visible (unless restricted by the use of filters) to all subsequent tasks in a process instance. Hence OpenWFE directly supports the Case Data pattern.
Folder Data - OpenWFE does not support folder data.
Workflow Data + OpenWFE supports globl data through the notion of engine variables (defined in the form //varname) that can be accessed at any point in any process.
Environment Data + OpenWFE supports environment data by defining separate participants for every external application (e.g. a web-service) from which such data is accessed. These participants can, just like any other participant, be invoked (i.e. have work distributed to them) from anywhere in a process.
Task to Task + OpenWFE supports this pattern through global shared data.
Block Task to SubWorkflow Decomposition + OpenWFE supports data interaction to sub-workflow decomposition both through 1) global sheared data; and through 2) parameter passing. (These apply both for sub-processes defined within the main process and for sub-processes residing outside the file with the main process definition.)
SubWorkflow Decomposition to Block Task + OpenWFE supports data interaction for sub-workflow decomposition through global sheared data.
To Multiple Instance Task - OpenWFE does not support this pattern as it lacks (multiple instances) task data.
From Multiple Instance Task - OpenWFE does not support data interaction from multiple instances tasks. After the completion of such a task only the values of the last instance to complete (or the first, depending on the specification) are stored.
Case to Case +/- OpenWFE supports case to case data interaction pattern as data can be passed between cases using global variables (of the form //globalVar). This is considered to constitute partial support for the pattern as it results in the more general communication of a data element from one case to all other cases, and not to one specific case as the pattern intends.
Task to Environment - Push-Oriented + OpenWFE supports data communication to the environment by defining separate participants for every external application (e.g. a web-service) to which data can be sent. These participants can then, be invoked (i.e. have work distributed to them) from anywhere in a process.
Environment to Task - Pull-Oriented + OpenWFE supports data requests from the environment by defining separate participants for every external application (e.g. a web-service) from which data is required. These participants can then, be invoked (i.e. have work distributed to them) from anywhere in a process.
Environment to Task - Push-Oriented - OpenWFE does not support this pattern.
Task to Environment - Pull-Oriented - OpenWFE does not support this pattern.
Case to Environment - Push-Oriented - OpenWFE does not support this pattern.
Environment to Case - Pull-Oriented - OpenWFE does not support this pattern.
Environment to Case - Push-Oriented - OpenWFE does not support this pattern.
Case to Environment - Pull-Oriented - OpenWFE does not support this pattern.

Workflow to Environment - Push-Oriented

 - OpenWFE does not support this pattern.
Environment to Workflow - Pull-Oriented - OpenWFE does not support this pattern.
Environment to Workflow - Push-Oriented - OpenWFE does not support this pattern.
Workflow to Environment - Pull-Oriented - OpenWFE does not support this pattern.
Data Transfer by Value - Incoming - OpenWFE does not support this pattern.
Data Transfer by Value - Outgoing - OpenWFE does not support this pattern.
Data Transfer - Copy In/Copy Out + OpenWFE is utilizing the Copy in/Copy out strategy when dealing with parallel tasks or multiple instance tasks. At creation, every work item receives a copy of the data values in the global vairabled. Any updates done on these values by a given work item instance remain invisible outside that work item. At completion the values associated with the work item (or one of them where the task is a multiple instance task) is copied back according to the strategy defined in the synchronization or multiple instances task construct, which may lead to lost update problems. To avoid this issue, filters can be used for individual parallel task in order to prevent simultaneous access to the same data element. However, filters can not be used to solve this issue for multiple instance tasks.
Data Transfer by Reference - Unlocked - OpenWFE does not support this pattern.
Data Transfer by Reference - With Lock + OpenWFE provides direct support for this pattern. As all data elements are global for a process, each of them resides at a location accessible by all process components. Concurrency restrictions are implied such that when a task has been started by one resource, the corresponding work item (and its associated data elements) get locked and the remaining resources with execution privileges for that task gets temporary read-only access to it.
Data Transformation - Input + OpenWFE supports data transformation on input data, as data transformations can be performed at any time between two tasks in a process.
Data Transformation - Output + OpenWFE supports data transformation on outup data, as data transformations can be performed at any time between two tasks in a process.
Task Precondition - Data Existence + OpenWFE supports this pattern as task precondition on data existence can be specified through <if>-then statements which contain an expression <defined variable-value="variable-name"> testing whether the variable variable-name has been defined or not.
Task Precondition - Data Value + OpenWFE supports the task precondition on data value pattern, as such preconditions can be defined through <if>-then statements testing the value of a field or a variable.
Task Postcondition - Data Existence - OpenWFE does not support this pattern.
Task Postconditon - Data Value - OpenWFE does not support this pattern.
Event-Based Task Trigger - Any support for this pattern was not observed in OpenWFE
Data-Based Task Trigger - Any support for this pattern was not observed in OpenWFE.
Data-Based Routing +/- OpenWFE supports the data-based routing pattern, through the <case> and <if>-then constructs. The support is rated as partial as there is no full support for the multi-choice variant of the pattern.

Evaluation results for OpenWFE version 1.7.3 against the workflow resource patterns

Pattern

Rating

Motivation
Direct Allocation - OpenWFE does not support this direct allocation as work is distributed to roles but not to individual resources.
Role-Based Allocation + In OpenWFE, when a work item is created, it is offered to a role.
Deferred Allocation + OpenWFE supports deferred allocation. It is implemented using variables which receive their values at runtime before the commencement of the relevant task.
Authorisation - OpenWFE does not support this pattern.

Seperation of Duties

 - OpenWFE does not support this pattern.
Case Handling - OpenWFE does not support this pattern.
Retain Familiar - OpenWFE does not support this pattern.
Capability Based Allocation - OpenWFE does not support this pattern.
History Based Allocation - OpenWFE does not support this pattern.
Organisational Allocation - OpenWFE does not support this pattern.
Automatic Execution + OpenWFE supports this pattern by providing the possibility to define any external application (which can implement automatic execution tasks) as participants to which work (in this case the execution of the corresponding applications) can be distributed.
Distribution by Offer - Single Resource - OpenWFE does not support this pattern.
Distribution by Offer - Multiple Resources + OpenWFE supports distribution by offer to multiple resources.
Distribution by Allocation - Single Resource - OpenWFE does not support this pattern.
Random Allocation - OpenWFE 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 OpenWFE.
Round Robin Allocation - OpenWFE 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 OpenWFE.
Shortest Queue - OpenWFE 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 OpenWFE.
Early Distribution - OpenWFE does not support this pattern.
Distribution on Enablement + In OpenWFE when a work item is created, it is immediately distributed.
Late Distribution - OpenWFE does not support this pattern.
Resource-Initiated Allocation - OpenWFE does not support this pattern.
Resource-Initated Execution - Allocated Work Item - OpenWFE does not support this pattern.
Resource-Initiated Execution - Offered Work Item + In OpenWFE, a work item offered to a shared group list is automatically started by a resource in the group by the resource selected "edit" for that work item.

System Determined Work Queue Content

 - OpenWFE does not support this pattern.
Resource-Determined Work Queue Content - OpenWFE does not support this pattern.
Selection Autonomy + OpenWFE supports this pattern.
Delegation - OpenWFE does not support this pattern. The commando "delegate" which is available when a work item is started implements the behaviour of the Reallocation pattern, as the task must have been started before the "delegate" menu becomes available.
Escalation + OpenWFE supports escalation through the timeout attribute for a task, which is used to limit the time duration for the task it is specified on. After a work item is timed out (which may occur both when the work item is waiting to be started or after it has been started) the flow either continues to the next task or the timed out work is re-distributed to another group work list. This escalation needs to explicitly be specified through an if-than statement where the identity of the new resource allocated to the task is defined.
Deallocation + In OpenWFE a started work item can be deallocated. Selecting the "cancel" menu results in a stateless deallocation with the work item being sent back to the group work list. Selecting the "save" menu results in a stateful deallocation. The semantics deviate slightly from those for the Deallocation pattern. As the state "allocated" is missing in OpenWFE, a work item needs to be started in order to be deallocated. This also implies that a distinction can be made between stateful and stateless deallocations.
Stateful Reallocation + In OpenWFE, once started a work item can be reallocated to another group of resources, which is done through the "delegate" menu. This form of reallocation is stateful. Reallocation of a work item can only be initiated by users who possess the "delegate" right on the store for which they are executing the work item in question.
Stateless Reallocation - OpenWFE does not support this pattern. Selecting the "delegate" menu during the execution of a work item results in a stateful reallocation.
Suspension/Resumption - OpenWFE does not support this pattern. Selecting "save" or "cancel" during the execution of a work item sends the work item back to the group work list from where everyone belonging to the group can select and continue it (which is the semantics for the Deallocation pattern).
Skip - OpenWFE does not support this pattern.
Redo +/- OpenWFE supports redo through the <cursor> construct for which only the "back" and "rewind" operations are allowed ("skip", "break" and "cancel" are disallowed in order to preserve the integrity of the overall process model). The support is partial, because in order to go back and redo a task, a user needs to have very detailed knowledge of the number of steps the process needs to be rewound. Not only task, but also all data-definition and manipulation steps in-between the tasks are counted by the rewind command.
Pre-Do - OpenWFE does not support this pattern.
Commencement on Creation - OpenWFE 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 - OpenWFE 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 - OpenWFE 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 - OpenWFE 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 +/- OpenWFE provides limited support for this pattern. When a user is defined, the privileges they have to access different stores are specified. "read" privileges to a user for a store implies that they wll be able to see both unallocated and started (i.e. allocated) work items in that store. This configuration can only be done by the workflow administrator. It is not possible to configure the visibility so that only unallocated (and not started) items get visible. Hence the degree of support is considered to be partial.
Configurable Allocated Work Item Visibility +/- OpenWFE provides limited support for this pattern. When a user is defined, the privileges they have to access different stores are specified. "read" privileges to a user for a store implies that they will be able to see both started (i.e. allocated) and unallocated work items in that store. This configuration can only be done by the workflow administrator. It is not possible to configure the visibility so that only started (and not unallocated) items get visible. Hence the degree of support is considered to be partial.
Simultaneous Execution - OpenWFE does not support this pattern.
Additional Resources - OpenWFE does not support this pattern.