Pattern 30 (Data Transfer by Reference - Unlocked)
FLASH animation of Data Transfer by Reference - Unlocked pattern
Description
The ability to communicate data elements between process components by utilizing a reference to the location of the data element in some mutually accessible location. No concurrency restrictions apply to the shared data element.
Example
The Finalise Interviewees task passes the location of the interviewee shortlist to all subsequent tasks in the Hire process.
Motivation
This Pattern is commonly utilised as a means of communicating data elements between process components which share a common data store. It involves the use of a named data location (which is generally agreed at design time) that is accessible to both the origin and target components and, in effect, is an implicit means of passing data as no actual transport of information occurs between the two components.
Overview
Figure 19 illustrates the passing of two data elements M and N (global and case level respectively) by reference from task instance A to B. Note that task instance B accepts these elements as parameters to internal data elements R and S respectively.
Figure 19: Data transfer by reference - unlocked
Context
There are no specific context conditions associated with this pattern.
Implementation
Reference-based data passing requires the ability for communicating process components to have access to a common data store and to utilize the same reference notation for elements that they intend to use co-jointly. There may or may not be communication of the location of shared data elements via the control channel or data channel (where supported) at the time that control flow passes from one component to the next. This mechanism for data passing is employed within the Staffware, FLOWer, COSA and iPlanet workflow engines and also within XPDL and BPEL.
Issues
The major issue associated with this form of data utilization is that it can lead to problems where two (or more) concurrent task instances access the same data element simultaneously. In the event that two or more of the task instances update the shared data element in a short interval, there is the potential for the "lost update problem" to arise where one of the task instances unwittingly overwrites the update made by another.
Solutions
The solution to this issue to to provide a means of limiting concurrent access to shared data elements where updates to its value are required. There are a variety of possible solutions to this, but the use of read and write locks is the most widely utilized scheme. The Data Transfer by Reference - With Lock pattern (WDP-31) embodies this solution.
Evaluation Criteria
An offering achieves full support if it has a construct that satisfies the description for the pattern.
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 | + | Achievable via fields |
Websphere MQ Workflow | 3.4 | - | Not supported |
FLOWer | 3.0 | + | Standard means of data passing |
COSA | 4.2 | + | Standard means of data passing |
XPDL | 1.0 | + | Directly supported where data is passed implicitly by shared variables |
BPEL4WS | 1.1 | + | No concurrency control is applied by default |
BPMN | 1.0 | - | Not supported |
UML | 2.0 | - | Not supported |
Oracle BPEL | 10.1.2 | + | No concurrency restrictions for accessing global data |
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. |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|