Pattern 13 (Multiple Instances with a priori Design-Time Knowledge)

FLASH animation of Multiple Instances with a priori Design-Time Knowledge pattern

Description

Within a given process instance, multiple instances of a task can be created. The required number of instances is known at design time. These instances are independent of each other and run concurrently. It is necessary to synchronize the task instances at completion before any subsequent tasks can be triggered.

Synonyms

None.

Examples

The Annual Report must be signed by all six of the Directors before it can be issued.

Motivation

This pattern provides the basis for concurrent execution of a nominated task a predefined number of times. It also ensures that that all task instances are complete before subsequent tasks are initiatied.

Overview

Similar to WCP12, the Multiple instances without Synchronization pattern, there are both sequential and simultaneous variants of this pattern illustrated in Figures 16 and 17 respectively. In both figures, task C is the one that executes multiple times.

Figure 16: Multiple instances with a priori design-time knowledge (variant 1)

Figure 17: Multiple instances with a priori design-time knowledge (variant 2)

Context

There is one context condition associated with this pattern: the number of task instances (i.e. numinst) is known at design time and is a fixed value.

Implementation

In order to implement this pattern, an offering must provide a specific construct in the process model that is able to denote the actual number of concurrent task instances that are required. Staffware, FLOWer, SAP Workflow and UML 2.0 ADs support the simultaneous variant of the pattern through the use of dynamic subprocedure, dynamic subplan, multi-line container element and ExpansionRegion constructs respectively. BPMN and XPDL support both options via the multi-instance loop task construct with the MI_Ordering attribute supporting both sequential and parallel values depending on whether the tasks should be started one-by-one or all together. Unlike other BPEL offerings which do not support this pattern, Oracle BPEL provides a <flowN> construct that enables the creation of multiple concurrent instances of a task.

Issues

Many offerings provide a work-around for this pattern by embedding some form of task invocation within a loop. These implementation approaches have two significant problems associated with them: (1) the task invocations occur at discrete time intervals and it is possible for the individual task instances to have distinct states (i.e. there is no requirement that they execute concurrently) and (2) there is no consideration of the means by which the distinct task instances will be synchronized. These issues, together with the necessity for the designer to effectively craft the pattern themselves (rather than having it provided by the offering) rule out this form of implementation from being considered as satisfying the requirements for full support.

Solutions

One possibility that exists where this functionality is not provided by an offering but an analogous form of operation is required is to simply replicate the task in the process-model. Alternatively a solution based on iteration can be utilized.

Evaluation Criteria

Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption. Although work-arounds are possible which achieve the same behaviour through the use of various constructs within an offering such as task replication or loops, they have a number of shortcomings and are not considered to constitute support 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.