Pattern 2 (Block Data)
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.
All components of the subprocess which define the Assess Investment Risk block task can utilise the security details data element.
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.
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
There are no specific context conditions associated with this pattern.
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.
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?
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.
An offering achieves full support if it satisfies the description for the pattern.
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.
|Staffware||9||+||Directly supported - each (sub)procedure can maintain a distinct set of data fields|
|Websphere MQ Workflow||3.4||+||Supported via global data containers for a process|
|FLOWer||3.0||+||Each plan can have its own data elements|
|COSA||4.2||+||Workflows can be nested and attributes of the form INSTANCE.name provide a means of supporting block data|
|XPDL||1.0||+||Supported through the block activity construct|
|BPEL4WS||1.1||-||Sub-processes are not supported|
|BPMN||1.0||+||Through the attribute Properties of a Sub-Process. The Properties defined for a Sub-Process are local and accessible to all Sub-Process components.|
|UML||2.0||+||Directly supported through parameters to activities which are accessible to all activity components|
|Oracle BPEL||10.1.2||-||Not supported|
jBPM does not support block data.
|OpenWFE||1.7.3||+||OpenWFE supports block data through the notion of sub-processes and local variable binding (i.e. through the notion of ./varname).|
|Enhydra Shark||2||+||Enhydra Shark does support block data through sub-flow variables, which are local for a sub-flow. (They are not visible to the calling process.) It is also possible to define block activities. However, variables in block processes are global for the entire workflow.|
Summary of Evaluation