Pattern 2 (Block Data)

FLASH animation of Block Data - Global pattern

FLASH animation of Block Data - Reference pattern

FLASH animation of Block Data - Value pattern

Description

Block tasks (i.e. tasks which can be described in terms of a corresponding subprocess) are able to define data elements which are accessible by each of the components of the corresponding subprocess.

Example

All components of the subprocess which define the Assess Investment Risk block task can utilise the security details data element.

Motivation

The manner in which a block task is implemented is usually defined via its decomposition into a subprocess. It is desirable that data elements available in the context of the undecomposed block task are available to all of the components that make up the corresponding subprocess. Similarly, it is useful if there is the ability to define new data elements within the context of the subprocess that can be utilised by each of the components during execution.

Overview

Figure 3 illustrates both of these scenarios, data element M is declared at the level of the block task C and is accessible both within the block task instance and throughout each of the task instances (X, Y and Z) in the corresponding subprocess. Similarly data element N is declared within the context of the subprocess itself and is available to all task instances in the subprocess. Depending on the actual offering, it may also be accessible at the level of the corresponding block task.

Figure 3: Block level data visibility

Context

There are no specific context conditions associated with this pattern.

Implementation

The concept of block data is widely supported and all of the offerings examined in this survey which supported the notion of subprocesses (footnote 1) implemented it in some form. Staffware allows subprocess to specify their own data elements and also provides facilities for parent processes to pass data elements to subprocesses as formal parameters. In Websphere MQ Workflow, subprocesses can specify additional data elements in the data container that is used for passing data between task instances within the subprocess and restrict their scope to the subprocess. FLOWer, COSA and iPlanet also provide facilities for specifying data elements within the context of a subprocess.

Issues

A major consideration in regard to block-structured tasks within a process is the handling of block data visibility where cascading block decompositions are supported and data elements are implicitly inherited by subprocesses. As an example, in the preceding diagram block data sharing would enable a data element declared within the context of task C to be utilised by task X, but if X were also a block task would this data element also be accessible to task instances in the sub-workflow corresponding to X?

Solutions

One approach to dealing with this issue adopted by workflow tools such as Staffware is to only allow one level of block data inheritance by default i.e. data elements declared in task instance C are implicitly available to X, Y and Z but not to further subprocess decompositions. Where further cascading of data elements is required, then this must be specifically catered for.

COSA allows a subprocess to access all data elements in a parent process and provides for arbitrary levels of cascading (footnote 2), however updates to data elements in subprocess are not automatically propagated back to the parent task.

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