Pattern 27 (Data Transfer by Value - Incoming)

FLASH animation of Data Transfer by Value - Incoming and Outgoing patterns

Description

The ability of a process component to receive incoming data elements by value avoiding the need to have shared names or common address space with the component(s) from which it receives them.

Example

At commencement, the Identify Successful Applicant task receives values for the required role and salary data elements.

Motivation

Under this scenario, data elements are passed as values between communicating process components. There is no necessity for each process component to utilize a common naming strategy for the data elements or for components to share access to a common data store in which the data elements reside. This enables individual components to be written in isolation without specific knowledge of the manner in which data elements will be passed to them or the context in which they will be utilized.

Overview

Figure 17 illustrates the passing of the value of data element R in task instance A to task instance B where it is assigned to data element S. In this example, a transient variable G (depending on the specific implementation, this could be a data container or a case or global variable) is used to mediate the transfer of the data value from task instance A to task instance B which do not share a common address space.

Figure 17: Data transfer by value

Context

There are no specific context conditions associated with this pattern.

Implementation

This approach to data passing is commonly used for communicating data elements between tasks that do not share a common data store or wish to share task-level (or block-level) data items. The transfer of data between process components is typically based on the specification of mappings between them identifying source and target data locations. In this situation, there is no necessity for common naming or structure of data elements as it is only the data values that are actually transported between interacting components. WebSphere MQ utilizes this approach to data passing in conjunction with distinct data channels. Data elements from the originating workflow task instance are coalesced into a data container. A mapping is defined from this data container to a distinct data container which is transported via the connecting data channel between the communicating tasks. A second mapping is then defined from the (transported) data container on the data channel to a data container in the receiving task. BPMN supports this style of data passing using the InputSets attribute for an activity (and OutputSets where the transfer is in the reverse direction). BPEL provides the option to pass data elements between activities using messages - an approach which relies on the transfer of data between process components by value. Similarly COSA provides analogous support using triggers although this does not allow for data types to be maintained during transfer. XPDL provides more limited support for data transfer by value between a block task and subprocess. As all data elements are case level, there is no explicit data passing between tasks. iPlanet supports a similar scheme.

Issues

None observed.

Solutions

N/A.

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description for the pattern. It rates as partial support if there are any limitations on the range of data elements or data values that can be passed or if the data passing action is not explicit.

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