Pattern 18 (Milestone)
FLASH animation of Milestone pattern
Description
A task is only enabled when the process instance (of which it is part) is in a specific state (typically a parallel branch). The state is assumed to be a specific execution point (also known as a milestone) in the process model. When this execution point is reached the nominated task can be enabled. If the process instance has progressed beyond this state, then the task cannot be enabled now or at any future time (i.e. the deadline has expired). Note that the execution does not influence the state itself, i.e. unlike normal control-flow dependencies it is a test rather than a trigger.
Synonyms
Test arc, deadline, state condition, withdraw message.
Examples
Most budget airlines allow the routing of a booking to be changed providing the ticket has not been issued;
The enrol student task can only execute whilst new enrolments are being accepted. This is after the open enrolment task has completed and before the close off enrolment task commences.
Motivation
The Milestone pattern provides a mechanism for supporting the conditional execution of a task or sub-process (possibly on a repeated basis) where the process instance is in a given state. The notion of state is generally taken to mean that control-flow has reached a nominated point in the execution of the process instance (i.e. a Milestone). As such, it provides a means of synchronizing two distinct branches of a process instance, such that one branch cannot proceed unless the other branch has reached a specified state.
Overview
The nominal form of the Milestone pattern is illustrated by Figure 24. Task A cannot be enabled when it received the thread of control unless the other branch is in state p1 (i.e. there is a token in place p1). This situation presumes that the process instance is either in state p1 or will be at some future time. It is important to note that the repeated execution of A does not influence the top parallel branch.
Figure 24: Milestone pattern
Note that A can only occur if there is a token in p1. Hence a Milestone may cause a potential deadlock. There are at least two ways of avoiding this. First of all, it is possible to define an alternative task of A which takes a token from the input place(s) of A without taking a token from p1. One can think of this task as a time-out or a skip task. This way the process does not get stuck if C occurs before A. Moreover, it is possible to delay the execution of C until the lower branch finishes. Note that in both cases A may be optional (i.e. not execute at all) or can occur multiple times because the token in p1 is only tested and not removed.
Context
There are no specific context conditions for this pattern.
Implementation
The necessity for an inheritent notion of state within the process model means that the Milestone pattern is not widely supported. Of the offerings examined, only COSA is able to directly represent it. FLOWer offers indirect support for the pattern through the introduction of a data element for each situation in which a Milestone is required. This data element can be updated with a value when the Milestone is reached and the branch which must test for the Milestone achievement can do so using the FLOWer milestone construct. Note that this is only possible in a data-driven system like FLOWer. It is not possible to use variables this way in a classical control-flow driven system because a "busy wait" would be needed to constantly inspect the value of this variable.
(Note that FLOWer only re-evaluates the state after each change with respect to data elements).
Issues
None identified.
Solutions
N/A
Evaluation Criteria
An offering achieves full support if it provides a construct that satisfies the description for the pattern. It receives a partial support rating if there is not a specific construct for the Milestone but it can be achieved indirectly.
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 | 10 | - | Not supported. There is no notion of state. |
Websphere MQ | 3.4 | - | Not supported. There is no inherent notion of state. |
FLOWer | 3.51 | +/- | There is no direct support for milestones since there is no notion of state. However, in all situations, data dependencies can be used to emaulate the construct. Simply introduce a data element (i.e., place in Petri net terms) for each state for which a milestone needs to be specified. |
COSA | 5.1 | + | Directly supported through places. |
iPlanet | 3.0 | - | Not supported. No concept of state. |
SAP Workflow | 4.6c | - | Not supported, because the concept of a state is completely missing. |
FileNet | 3.5 | - | Not supported: although FileNet has a concept of milestone, it refers to the following: To track the progress of a workflow, the workflow author can define key points (milestones) in the workflow. On the workflow map, a milestone can be placed either before or after a General step, or after the Launch step. When the running workflow reaches a milestone, an author-specified message is written to a log file and, depending on its author-specified level (1 to 99), the milestone displays for workflow participants, trackers, and the user who launched the workflow. The Milestones page displays a list of milestones that have been reached for a workflow. You can only access this page from the email message sent to the workflow originator when the milestone is reached. |
BPEL | 1.1 | - | Indirectly achievable by using a <pick> construct within a <while> loop which can only be executed once but solution is overly complex. |
Websphere Integration Developer | 6.0 | - | Indirectly achievable by using a <pick> activity within a <while> loop which can only be executed once but solution is overly complex. |
Oracle BPEL | 10.1.2 | - | Indirectly achievable by using a <pick> activity within a <while> loop which can only be executed once but solution is overly complex. |
BPMN | 1.0 | - | Not supported. No support for states. |
XPDL | 2.0 | - | Not supported. No concept of state. |
UML ADs | 2.0 | - | Not supported. No notion of state within UML 2.0 ADs. |
EPC (implemented by ARIS toolset 6.2) | - | Not supported. Although EPCs contain events, it is not possible to check states and act accordingly. | |
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. The notion of state is not present in the tool . |