Workflow Concept of WS-PGRADE/gUSE - Science Gateways for Distributed Computing Infrastructures - page 47

Although conditional job execution looks familiar, with the execution of com-
plete branches depending on input data, there are some speci c cases to consider at

the point of merging these branches. First, for both of the alternate branches rep-
resented by jobs,

“ True ” and “ False ” must have disjunctive data-dependent con-

ditions (job ). As

was proven in Balasko (2013b), this is equivalent to the deferred choice pattern.
Then, to ensure the execution of job

“ True ” must equal value “ true ” ; job “ False ” must not equal “ true ”

independently from the job executed
before, which implements the simple merge pattern, both incoming ports of the job
“

“ Post ”

must be set to the same internal name (the alternate executions produce the
same output

Post ”

file name). It must be set to have the collector property that allows job
submission against a set of files, including the case of that set being empty.

Otherwise, following the general semantics, job would not be submitted

since it requires an input from both of the branches, including the disabled branch
as well, which does not produce any inputs.

“ Post ”

3.8 Sharing and Archiving Work fl ows

At the end of the lifecycle of a workflow, its developer has the privilege to share
his/her workflow with colleagues who work on the same portal (so, within the
community), or enabling its use by others for different communities (called cross-
community sharing). Both ways are supported by WS-PGRADE/gUSE. In the prior
case, the users export their workflow to the internal repository, which publishes it to
all users after importing it in the same portal server. The latter case is based on the
integration of a third-party solution for storing workflows that are accessible world-
wide, called the SHIWA repository. It follows a more sophisticated solution.
During the export process the users can choose which arguments or input files are

mandatory for the execution, and which can be changed. This information indicates
a more clear view for an exported workflow than what an internal repository offers.
It is discussed in detail in Chap. 9 .
Besides sharing workflows, they can be also downloaded to be moved to other
portals without sharing. During this process the workflow graph and the con gu-

ration are collected and stored as the XML introduced in Sect. 3.2 . Together with
the input file. The users

are free to download the whole workflow with or without all the executed workflow
instances.

files and binaries uploaded, it is compressed as a single zip

3.9 Conclusions

In this chapter we introduced the features and the capabilities of the gUSE work-
flow language, in which the workflow applications can be de

ned. All the features
and all the common workflow structures were described using Dataflow patterns.