Pattern 28 (Data Transfer by Value - Outgoing)
The ability of a process component to pass data elements to subsequent components as values avoiding the need to have shared names or common address space with the component(s) to which it is passing them.
Upon completion, the Identify Successful Applicant task passes the successful applicant name to the next task.
Similar to Data Transfer by Value - Incoming pattern (WDP27) although in this scenario, the emphasis is on minimising the coupling between a component and the subsequent components that may receive its output data.
There are no specific context conditions associated with this pattern.
An offering achieves full support if it has a construct that satisfies the description of 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 passed action is not explicit.
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.
|Websphere MQ Workflow||3.4||+||All data passing via containers is by value|
|COSA||4.2||+/-||As for Pattern 27|
|XPDL||1.0||+/-||As for Pattern 27|
|BPEL4WS||1.1||+||Option to pass data elements between activities by value (using messages)|
|BPMN||1.0||+||Supported through the notion of OutputSets of Activites|
|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 from sub-flows back to its calling process 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