Pattern 17 (Environment to Task - Push)
FLASH animation of Data Interaction - Environment to Task - Push-Oriented pattern
Description
The ability for a task to receive and utilise data elements passed to it from services and resources in the operating environment on an unscheduled basis.
Example
During execution, the Review Performance task may receive new engine telemetry data from the Wireless Car Sensors .
Motivation
An ongoing difficulty for tasks is establishing mechanisms that enable them to be provided with new items of data as they become available from sources outside of the process environment. This is particularly important in areas of volatile information where updates to existing data elements may occur frequently but not on a scheduled basis, e.g. price updates for equities on the stock market. This pattern relates to the ability of tasks to receive new items of data as they become available without needing to proactively request them from external sources or suspend execution until updates arrive.
Overview
As for patterns 15 and 16, approaches to this pattern can be divided into explicit and implicit mechanisms. The main difficulty that arises in its implementation is in providing external processes with the addressing information that enables the routing of data elements to a specific task instance. Potential solutions to this include the provision of externally accessible execution monitors by offerings which indicate the identity of currently executing tasks or task instances recording their identity with a shared registry service in the operating environment.
An additional consideration is the ability of tasks to be able to asynchronously wait for and respond to data passing activities without impacting the actual progress of the task. This necessitates the availability of asynchronous communication facilities at task level - either provided as some form of ( explicit ) task construct by the PAIS or able to be ( implicitly ) included in the programmatic implementations of tasks.
Context
There are no specific context conditions associated with this pattern.
Implementation
A number of the offerings examined support this pattern in some form. COSA provides the ability to pass data elements to tasks via the trigger construct as well as via various APIs. BPEL provides a similar capability with the receive construct and event handlers. iPlanet provides facilities for developing "adaptor" and "proxy" tasks through which external data can be delivered to a process instance. FLOWer allows the value of data elements associated with task forms to be updated via the chp_frm_setfield API call. BPMN supports the pattern using a Message Flow from the Pool representing the environment to the relevant Task. In Staffware, this pattern can be indirectly achieved by using the Event Step construct which allows external processes to update field data during the execution of a case. However, a "dummy" task is required to service the query request.
Issues
The major difficulty associated with this Pattern is in providing a means for external applications to identify the specific task instance in which they wish to update a data element.
Solutions
In general the solution to this problem requires the external application to have knowledge of both the case and the specific task in which the data element resides. Details of currently executing cases can only be determined with reference to the process environment and most offerings provide a facility or API call to support this requirement. The external application will most likely require a priori knowledge of the identity of the task in which the data element resides.
Evaluation Criteria
An offering achieves full support if it has a construct that satisifies the description for the pattern. It achieves a partial support rating if programmatic extensions are required to facilitate the data passing.
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 | +/- | Indirectly supported by Event Steps |
Websphere MQ Workflow | 3.4 | +/- | Indirectly achievable by including communication facilities in program implementations |
FLOWer | 3.0 | +/- | Values of data elements in forms associated with tasks can be updated via CHIP library API |
COSA | 4.2 | + | Supported via command line and C/COM/Java APIs |
XPDL | 1.0 | - | Not reported |
BPEL4WS | 1.1 | +/- | Indirectly achievable via the receive construct or event handlers although the data update operation requires specific coding |
BPMN | 1.0 | + | Captured through a message flow flowing from the boundary of a Pool representing the Environment to a Task |
UML | 2.0 | - | Not supported |
Oracle BPEL | 10.1.2 | + | Directly support via <receive> and event handlers |
jBPM | 3.1.4 | - | jBPM does not support this pattern. |
OpenWFE | 1.7.3 | - | OpenWFE does not support this pattern. |
Enhydra Shark | 2 | - | Enhydra Shark does not support this pattern. It is indeed possible to implement a ToolAgent that acts as an event listener. However, the actual behaviour of an event listener corresponds to the pattern Environment to Task-Pull, as the listener watches for updates. |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|