Pattern 16 (Environment to Task - Pull)
FLASH animation of Data Interaction - Environment to Task - Pull-Oriented pattern
Description
The ability of a task to request data elements from resources or services in the operational environment.
Example
The Determine Cost task must request cattle price data from the Cattle Market System before it can proceed.
Motivation
Tasks require the means to proactively seek the latest information from known data sources in the operating environment during their execution. This may involve accessing the data from a known repository or invoking an external service in order to gain access to the required data elements.
Overview
Similar to Data Interaction - Task to Environment - Push-Oriented pattern (WDP-15), distinct PAIS support this pattern in a variety of ways however these approaches divide into two categories:
- Explicit integration mechanisms - where the PAIS provides specific constructs for accessing data in the external environment.
- Implicit integration mechanisms - where access to external data occurs at the level of the programmatic implementations that make up tasks in the offering and is not directly supported by the PAIS. Interaction with external data sources typically utilises interprocess communication (IPC) facilities provided by the operating system facilities such as message queues or remote procedure calls, or enterprise application integration (EAI) mechanisms such as DCOM (footnote 8), CORBA (footnote 9) or JMS (footnote 10).
Context
There are no specific context conditions associated with this pattern.
Implementation
Staffware provides two distinct constructs that support this objective. Automatic Steps allow external systems to be called (e.g. databases or enterprise applications) and specific data items to be requested. Scripts allow external programs to be called either directly at system level or via system interfaces such as DDE (footnote 11) to access required data elements. FLOWer utilises Mapping Objects to extract data elements from external databases. COSA has a number of Tool Agent facilities for requesting data from external applications. Similarly, iPlanet provides a range of XML and HTTP-based integration functions that can be included in task implementations for requesting external data. BPMN supports the pattern via a pair of Message Flows, one from a Task to the boundary of a Pool representing the environment and the other in the reverse direction thus depicting a synchronous data request. XPDL and BPEL provide facilities for the synchronous request of data from other web services. In contrast, Websphere MQ does not provide any facilities for external integration and requires the underlying programs that implement workflow tasks to provide these capabilities where they are required.
Issues
One difficulty with this style of interaction is that it can block progress of the requesting case if the external application has a long delivery time for the required information or is temporarily unavailable.
Solutions
The only potential solution to this problem is for the requesting case not to wait for the requested data (or continue execution after a nominated timeout) and to implement some form of asynchronous notification of the required information (possibly along the lines of Pattern 17). The disadvantage of this approach is that it complicates the overall interaction by requiring the external application to return the required information via an alternate path and necessitating the workflow to provide notification facilities.
Evaluation Criteria
An offering achieves full support if it has a construct that satisfies 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 | + | Directly supported via Automatic Steps and script functions |
| Websphere MQ Workflow | 3.4 | +/- | Indirectly achievable by including communication facilities in program implementations |
| FLOWer | 3.0 | + | Supported via the mapping construct using In type |
| COSA | 4.2 | + | Supported through tool agents e.g. ODBC |
| XPDL | 1.0 | + | Data can be synchronously requested from other web services |
| BPEL4WS | 1.1 | + | The invoke construct also supports the request of data elements from other web services on a synchronous basis |
| BPMN | 1.0 | + | Captured through a message flow flowing from a Task to the boundary of a Pool representing the Environment, followed by a message flow from the Pool (representing the Environment) back to the task |
| UML | 2.0 | - | Not supported |
| Oracle BPEL | 10.1.2 | + | Direct support via <invoke> and <receive> |
| jBPM | 3.1.4 | +/- | External data interaction in jBPM is realized at task (and transition) level. Data Interaction -- Environment to Task -- Pull oriented is implemented through Nodes which can stop and await the receipt of the data they are pulling from the external source. Due to the java coding which is needed in order to get the data interaction working, the support for this pattern is considered as partial. |
| OpenWFE | 1.7.3 | + | OpenWFE supports data requests from the environment by defining separate participants for every external application (e.g. a web-service) from which data is required. These participants can then, be invoked (i.e. have work distributed to them) from anywhere in a process. |
| Enhydra Shark | 2 | +/- | Enhydra Shark supports this pattern partially. See the comment for pattern 15. |
Summary of Evaluation
+ Rating |
+/- Rating |
|---|---|
|
|