Pattern 2 (Role-Based Distribution)

FLASH animation of Role-Based Distribution pattern

Description

The ability to specify at design-time one or more roles to which instances of this task will be distributed at runtime. Roles serve as a means of grouping resources with similar characteristics. Where an instance of a task is distributed in this way, it is distributed to all resources that are members of the role(s) associated with the task.

Example

Instances of the Approve Travel Requisition task must be executed by a Manager.

Motivation

Perhaps the most common approach to work item distribution within PAIS, Role-based Distribution offers the means for the PAIS to route work items to suitably qualified resources at runtime. The decision as to which resource actually receives a given work item is deferred until the moment at which it becomes "runnable" and requires a resource distribution in order for it to proceed. The advantage offered by Role-based Distribution (over other work item distribution schemes) is that roles can be defined for a given process that identify the various classes of available resources to undertake work items. Task definitions within the process model can nominate the specific role to which they should be routed, however the actual population of individual roles does not need to occur until runtime.

Overview

The Role-based Distribution pattern is specified as a relationship between a task and a (non-empty) group of roles. At runtime, work items associated with the task are distributed to one or more of the resources participating in these roles.

Context

There are no specific context conditions associated with this pattern.

Implementation

All of the offerings examined support Role-based Distribution in some form. Generally roles serve as groupings of resources with similar characteristics or authority and provide a means of decoupling the routing of a work item from that of resource management. The most restrictive approach to role definition occurs in Staffware where only one resource can be identified for each role although it is possible to specify multiple roles when defining the routing of a work item. WebSphere MQ allows multiple resources to be specified for each role and also multiple roles to be used when routing a work item. iPlanet supports roles in a similar way although the actual mechanism used for work item distribution takes the form of an expression which includes the various roles rather than simply listing the roles to which the work item will be forwarded. COSA also uses roles as a grouping mechanism for resources and allows them to be used as a routing mechanism for work items, however where a work item is routed to multiple resources, it appears on a shared (group) work queue rather than being replicated on the work lists of individual resources. COSA provides support for explicitly representing quite complex organizational structures and work distribution mechanisms by allowing role, organizational and authorization hierarchies to be distinctly modelled and drawn together where required in the distribution functions for individual work items. FLOWer supports multiple users per role and allows a user to play different roles in distinct cases. Roles serve as the main basis of work item distribution although resources have a reasonable degree of autonomy in selecting the work items (and cases) that they will undertake rather than having work items directly assigned to them. BPMN and UML 2.0 ADs support roles through the use of pools and swimlane constructs. Oracle BPEL supports the pattern although it does not differentiate between roles and groups and a work item distributed to a role is visible in the worklist of all members of that role.

Issues

In some PAIS, the concepts of roles and groups are relatively synonymous. Roles serve as an abstract grouping mechanism (i.e. not just for resources with similar characteristics or authority, but also for identification of organisational units (e.g. teams, departments etc.)) and provide a means of distributing work across a number of resources simultaneously. One difficulty that arises with this use of roles occurs where the intention is to offer a work item to several resources with the expectation that they will all work on it.

Solutions

Staffware provides support for group-based work distribution. It operates in much the same way as Role-based Distribution with groups being identified within the workflow system consisting of several resources. Individual resources may belong to more than one group (unlike the situation with roles) and a task within the process model can be specified as requiring routing to a specific group at runtime. However the operation of group-based distribution differs from Role-based Distribution at run-time with a work item that is allocated to a group being visible to all of the resources in the group and not specifically (and privately) assigned to one of them during the allocation process. Group-based distribution is non-deterministic with respect to resources and the work item is ultimately allocated to the first resource in the group that commences work on it. From this point, none of the other resources in the group can execute it although it remains in the work queue of all the resources until it has been complete. As indiciated above, Oracle BPEL does not differentiate between roles and groups, however only one of the users corresponding to a given role can actually undertake a work item where it is subject to role-based distribution. None of the other offerings examined provide support for this approach to work distribution.

Evaluation Criteria

An offering achieves full support if it satisfies the description for the pattern.

Product Evaluation

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.

Summary of Evaluation