Pattern 27 (Data Transfer by Value - Incoming)

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


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.


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


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.


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

Figure 17: Data transfer by value


There are no specific context conditions associated with this pattern.


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.


None observed.



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.





Staffware 9 - Not supported
Websphere MQ Workflow 3.4 + All data passing via containers is by value
FLOWer 3.0 - Not supported
COSA 4.2 +/- Achievable via triggers although limitation on range and typing of parameters passed
XPDL 1.0 +/- Although call by value is the standard mechanism (see Section, there is not explicit data passing between activities. However, the element "subflow" provides actual parameters which should be matched by the formal parameters of the corresponding workflow process
BPEL4WS 1.1 + option to pass data elements between activities by value (using messages)
BPMN 1.0 + Supported though the notion of InputSets of Activities
UML 2.0 - Not supported
Oracle BPEL 10.1.2 + Directly supported by the attributes of <assign> wizard
jBPM 3.1.4 - jBPM does not support this pattern.
OpenWFE 1.7.3 - OpenWFE does not support this pattern.
Enhydra Shark 2 +/- In Enhydra Shark, data is passed to sub-flows through parameters. Parameters are not used for passing data between any other kinds of activities (as data is global for a workflow) hence the support for this pattern is ranked as partial.

Summary of Evaluation

+ Rating

+/- Rating

  1. Workflow components are able to accept data elements passed to them as values
  1. Achievable via programmatic extensions