Pattern 9 (Task to Task)
FLASH animation of Data Interaction - Task to Task - Distinct Control and Data Channels pattern
FLASH animation of Data Interaction - Task to Task - Integrated Control and Data Channels pattern
FLASH animation of Data Interaction - Task to Task - Global Data Store pattern
Description
The ability to communicate data elements between one task instance and another within the same case. The communication of data elements between two tasks is specified in a form that is independent of the task definitions themselves.
Example
The Determine Fuel Consumption task requires the coordinates determined by the Identify Shortest Route task before it can proceed.
Motivation
The passing of data elements between tasks is a fundamental aspect of PAIS. In many situations, individual tasks execute in their own distinct address space and do not share significant amounts of data on a global basis. This necessitates the ability to move commonly used data elements between distinct tasks as required.
Overview
All PAIS support the notion of passing parameters from one task to another however, this may occur in a number of distinct ways depending on the relationship between the data perspective and control flow perspective within the offering. There are three main approaches as illustrated in Figure 10.
Figure 10: Approaches to data interaction between tasks
The distinctions between each of these are as follows:
- Integrated control and data channels - where both control flow and data are passed simultaneously between tasks utilising the same channel. In the example, task B receives the data elements X and Y at exactly the same time that control is passed to it. Whilst conceptually simple, one of the disadvantages of this approach to data passing is that it requires all data elements that may be used some time later in the process to be passed with the thread of control regardless of whether the next task will use them or not. For example, task B does not use data element Y but it is passed to it because task C will subsequently require access to it.
- Distinct data channels - in which data is passed between tasks via explicit data channels which are distinct from the process control links within the process design. Under this approach, the coordination of data and control passing is usually not specifically identified. It is generally assumed that when control is passed to a task that has incoming data channels, the data elements specified on these channels will be available at the time of task commencement.
- Global data store - where tasks share the same data elements (typically via access to globally shared data) and no explicit data passing is required (cf. the Case Data and Folder Data patterns). This approach to data sharing is based on tasks having shared a priori knowledge of the naming and location of common data elements. It also assumes that the implementation is able to deal with potential concurrency issues that may arise where several task instances seek to access the same data element.
Context
There are no specific context conditions associated with this pattern.
Implementation
The majority of offerings examined adopt the third strategy. Staffware, FLOWer, COSA, XPDL and UML 2.0 ADs all facilitate the passing of data through case-level data repositories accessible by all tasks. BPEL utilises a combination of the first and third approaches. Variables can be bound to scopes within a process definition which may encompass a number of tasks, but there is also the ability for messages to be passed between tasks when control passes from one task to another. Websphere MQ adopts the second mechanism with data elements being passed between tasks in the form of data containers via distinct data channels. BPMN supports all three implementation alternatives allowing data to be passed using specific Data Objects (which may or may not be linked to a Sequence Flow depending on whether an integrated control and data channel is required) or via the Properties attribute of a task.
Issues
There are several potential issues associated with the use of this pattern. First, where there is no data passing between tasks and a common data store is utilised by several tasks for communicating data elements, there is the potential for concurrency problems to arise, particularly if the case involves parallel execution paths. This may lead to inconsistent results depending on the task execution sequence that is taken.
A second consideration arises where data and control flow are passed along the same channel. In this situation there is the potential for two (potentially differing) copies of the same data element to flow to the same task (footnote 4), necessitating that the task decide which is the correct version of the data element to use it its processing activities.
A third consideration where data and control-flow occur via distinct channels, is that of managing the situation where the control-flow reaches a task before the required data elements have been passed to it.
Solutions
The first issues - concurrency control - is handled in a variety of different ways by the offerings examined. FLOWer avoids the problem by only allowing one active user or process that can update data elements in a case at any time (although other processes and users can access data elements for reading). BPEL supports serialisable scopes which allow compensation handlers to be defined for groups of tasks that access the same data elements. A compensation handler is a procedure that aims to undo or compensate for the effects of the failure of a task on other tasks that may rely on it or on data that it has affected. Staffware provides the option to utilise an external transaction manager (Tuxedo) within the context of the workflow cases that it facilitates.
In terms of the second issue, no general solutions to this problem have been identified. Of the offerings observed, only BPEL supports the simultaneous passing of control-flow and data along the same channel and it does not provide a solution to the issue.
The third issue is addressed in WebSphere MQ (which has distinct data and control-flow channels) by ensuring that the task instance waits for the required data elements to arrive before commencing execution.
Evaluation Criteria
An offering achieves full support if it has a construct that 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.
Product/Language |
Version |
Score |
Motivation |
|---|---|---|---|
| Staffware | 9 | + | Data interaction between tasks is based on use of common block-level data fields |
| Websphere MQ Workflow | 3.4 | + | Facilitated via data containers passed between tasks on data channels |
| FLOWer | 3.0 | + | Supported by shared data elements |
| COSA | 4.2 | + | Supported by data sharing (implicit data passing) |
| XPDL | 1.0 | + | All tasks refer to the same data |
| BPEL4WS | 1.1 | + | Data elements can be passed between activities in messages or via shared variables |
| BPMN | 1.0 | + | i) Through integrated control and data channels. Supported through the notion of Data Objects associated to Sequence Flows. ii) Through distinct control and data channels. Supported through the notion of Data Objects with its Properties attribute. iii) Through global shared data. Global shared data is supported through the attribute Properties of a Process. |
| UML | 2.0 | + | Directly supported by the ObjectNode construct. |
| Oracle BPEL | 10.1.2 | + | No data passing; data elements shared between tasks via access to globally shared data |
| jBPM | 3.1.4 | + | jBPM supports this pattern through global shared data. |
| OpenWFE | 1.7.3 | + | OpenWFE supports this pattern through global shared data. |
| Enhydra Shark | 2 | + | Enhydra Shark supports this pattern through case variables. |
Summary of Evaluation
+ Rating |
+/- Rating |
|---|---|
|
|