Pattern 5 (Separation of Duties)
The ability to specify that two tasks must be executed by different resources in a given case.
Instances of the Countersign cheque task must be allocated to a differnt resource to that which executed the Prepare cheque task in a given case.
Separation of Duties allows for the enforcement of audit controls within the execution of a given case. The Seperation of Duties constraint exists between two tasks in a process model. It ensures that within a given case, work items corresponding to the latter task cannot be executed by resources that completed work items corresponding to the former task. Another use of this pattern arises with PAIS that support multiple task instances. In this situation, the degree of parallelism that can be achieved when a multiple instance task is executed can be maximised by specifying that as far as possible no two task instances can be executed by the same resource.
The Separation of Duties pattern relates a task t to a number of other tasks that precede it in the process. Within a given case, work items corresponding to task t cannot be distributed to any resource that previously completed work items corresponding to tasks with which t has a Separation of Duties constraint. As it is possible that preceding tasks may have executed more than once within a given case, e.g. they may be contained within a loop or have multiple instances, there may be a number of resources that are excluded from undertaking instances of task t.
There are no specific context conditions associated with this pattern.
This pattern can be implemented in a number of distinct ways:
- WebSphere MQ and FLOWer provide the ability to specify at task level, a link with another (preceding) task. At runtime, the work item corresponding to the task cannot be allocated to the same resource as that which undertook the last instance of the work item corresponding to the linked task.
- iPlanet utilizes the concepts of linked activities which allow the data elements of two distinct tasks to be shared and evaluate methods which define how the work items for a given task will be allocated to the various resources within the workflow system. For a given task, a custom evaluate method can be constructed which ensures it cannot be allocated to the same resource that undertook the (preceding) instance of the task to which it was linked.
- COSA allows the effect of Separation of Duties to be achieved through the use of access rights which restrict the resource which undertook the preceding work item from executing the latter.
An offering achieves full support if it satisfies the description for the pattern. It achieves a partial support rating where the same effect can be achieved indirectly, e.g. using access rights on tasks or security constraints.
To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.
|Websphere MQ Workflow||3.4||+||Directly supported via task linking between activities in the process model that cannot have the same resource allocation at runtime within a case|
|FLOWer||3.0||+||Achieved by specifying additional execution constraints (not same user) on plan elements|
|COSA||4||+/-||Indirectly achievable through user access rights|
|iPlanet||3.1||+||Directly supported through linked activities|
|Oracle BPEL||10.1.2||-||Oracle BPEL does not allow specifying the separation of duties in terms of relationships between tasks, nor it allows the separation of duties based on security mechanisms. Thus this pattern is not supported by Oracle BPEL PM.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|
Summary of Evaluation