WPI's Workflow Control Patterns and CWL
Note: CWL is a data-driven (dataflow) workflow standard. These patterns use control-flow language and thus we speak of the equivalent data-flow constructs. There is no concept of "thread of control" in CWL.
Of the 43 WPI Workflow Control patterns, 8 patterns are supported by CWL v1.2 or earlier and 35 patterns are unsupported.
Back to the list of WPI pattern categories
Yes. CWL is a DAG based workflow language with explicit dependencies between steps.
CWL versions: all
Yes. Anytime a step in a CWL workflow has all of its inputs available it is allowed to be executed.
CWL versions: all
Yes. One can have a step in a CWL workflow that requires inputs from the result of multiple other steps. Downstream steps that require the output of that step (and their descendents) will not be available for execution until the combination step has finished.
CWL versions: all
Yes. No explicit construct, but can be achieved by marking the two downstream steps with the when CWL conditional step
execution feature where the logic for one step's when field is the inverse of the other step's when field.
If there is a downstream workflow step that would inherit an value from one of the exclusive choice steps into the same incoming input port, then pickValue: the_only_non_null may be helpful to ensure that both "exclusive" choices didn't execute due to a misconfiguration in their when logics.
CWL versions: v1.2+
Yes. Any workflow can include another workflow as a step, thus allowing re-use.
CWL versions: all
No, as there is not a construct in CWL to implement this directly, as required by the WPI definition of this pattern.
Can be emulated using the CWL v1.2 when similar to the method to implement Pattern 4 (Exclusive choice), but with 3 or more steps using matched when markers
No, as there is not a construct in CWL to implement this directly, as required by the WPI definition of this pattern.
One way to achieve this is to hide the choice inside a sub-workflow which will provide a stable set of outputs to connect to other steps.
As this pattern implies the conditional execution of prior steps, the use of the pickValue construct in the merge step will likely be useful.
No, as CWL does not have a construct for the WPI Multi-Choice pattern, which is a pre-requisite for the WPI definition of the Multi-Merge pattern.
However, any CWL step can rely on inputs from multiple other steps. This functionality is available in all CWL versions.
No. CWL does not support canceling the execution of tasks according to some criteria.
No. State in CWL is read-only, therefore this pattern is not supported as it would be impossible to reset the discriminator. This pattern is likely not possible in CWL for other reasons as well.
No. CWL does not support canceling the execution of tasks according to some criteria. Additionally, all variables in CWL are read-only so there is no ability to "reset [a] construct".
No. CWL does not support canceling the execution of tasks according to some dynamic criteria.
No. CWL does not support re-ordering of tasks.
No. CWL does not support canceling the execution of tasks according to some criteria.
No. CWL is a dataflow workflow language, not a control-flow workflow language. All inputs must be known at the time of workflow enactment.
No. CWL is a dataflow workflow language, not a control-flow workflow language.
A CWL step can not accumulate inputs (or continue to emit outputs) over time.
CWL steps are only executed once (unless scatter is used) and the results of that step are only made available once execution has finished.
See also the evaluation of CWL against Pattern 7 (Structured Synchronizing Merge).
Yes, as this was easy to implement due to two factors related to CWL being a dataflow workflow language and not a control-flow workflow language:
-
CWL steps are only executed once (unless
scatteris used) and the results of that step are only made available once execution has finished. -
A CWL step is available for execution when all of the upstream steps have been executed (or permanently skipped due to the use of the
whenconstruct).
CWL versions: without conditional steps: all with contional steps: v1.2+
No, CWL has no concept of threads at the workflow language level. The underlying applications may use POSIX threads, but that is not managed by CWL.
No, CWL has no concept of threads at the workflow language level. The underlying applications may use POSIX threads, but that is not managed by CWL.
No. While CWL has the scatter construct, using this implies an implicit "gather"ing of the results before downstreams steps can use the results.
This means that execution of subsequent steps is delayed for the slowest execution of the the scattered tasks, even if that particular result isn't needed right away.
Additionally, CWL does not have a loop construct, which would be another way one could implement this pattern.
No. There is no CWL construct to execute a step or task a specific N number of times, where N is a concrete number (like 23) specified by the workflow author.
Additionally, CWL does not have a loop construct, which would be another way one could implement this pattern.
However: this pattern could be emulated in a CWL editor or language that converts to CWL syntax by creating explicit steps (23 in our example) in the CWL workflow description.
Yes. CWL has the scatter construct which allows a compact directive that a given step is to be executed multiple times where most inputs are fixed except for those scattered specified inputs.
No. CWL lacks any construct that can spawn additional tasks dynamically according to criteria.
No. CWL does not have the ability to allow execution of a downstream step when N of M tasks have completed.
No. CWL does not support canceling the execution of tasks according to some criteria.
No. CWL lacks any construct that can spawn additional tasks dynamically according to criteria.
No. The CWL v1.2+ conditional workflow step ability is only based upon explict inputs to the workflow step.
Additionally, in CWL there is no concept of an "operating environment".
No. Ordering of tasks in CWL is not fixed, but the dependecy graph is explicit.
There is no CWl construct to limit the number of parallel tasks being executed, that is up to the workflow engine.
No. In CWL, parameter values are read-only; they can not change over time.
It is not possible to query the state of another CWL task.
A step in a CWL workflow can only recieve specific outputs from other steps that have already completed, and this wiring is fixed prior to workflow execution.
No. Sub sections of CWL workflows can not be bidirectionally connected. One could depend on another (by putting the other in a sub-workflow, if it isn't one already).
It is not possible to query the state of another CWL task.
A step in a CWL workflow can only recieve specific outputs from other steps that have already completed, and this wiring is fixed prior to workflow execution.
No. Ordering of tasks in CWL is not fixed, but the dependecy graph is explicit.
There is no CWl construct to limit the number of parallel tasks being executed, that is up to the workflow engine.
No. CWL does not support canceling the execution of tasks according to some criteria.
No. CWL does not support canceling the execution of tasks according to some criteria.
Additionally, CWL does not have the concept of a "case".
No. CWL does not support canceling the execution of tasks according to some criteria.
No. CWL does not support canceling the execution of tasks according to some criteria.
No. CWL does not support canceling the execution of tasks according to some criteria.
No. CWL has no loop construct.
No. CWL has no loop construct.
No. CWL does not support recursion.
Yes. CWL workflows are finished when all of the required outputs are available.
No. CWL does not have an explicit "end node" construct.
No. CWL does not support the concept of triggers or signals.
No. CWL does not support the concept of triggers or signals.