Computational Neuroscience Gateway: A Science Gateway Based on the WS-PGRADE/gUSE - Science Gateways for Distributed Computing Infrastructures - page 138

determine the location from which the inputs should be retrieved and where to save
the output, which are con gured by the PM during submission. The details needed

to run the application are obtained by querying eCAT, such as the gUSE application
ID, the DCI on which the application is con

gured to execute, as well as the input
and output ports, and the relationship between them. All applications are con gured

to run with a community grid certi cate, which is

stored securely in the MyProxy server. The PM uses the gUSE ASM API to utilize
gUSE services, more speci

cate, also known as “ robot ” certi

cally the gUSE application repository and the gUSE

WFI.
The user starts a data processing by selecting input files and an application to

process them. Each data processing can generate one or more submissions. This
depends on the number of inputs and the relationship between inputs and the outputs
for each application. In most applications, one output is generated for each input. In
these cases the processing consists of n workflow submissions, one for each of the
n inputs. In other applications, a single output is generated for a collection of inputs,
and therefore a single workflow is submitted. Submitting one workflow for each
input, instead of using parameter sweep capabilities of the workflow interpreter, is
motivated by the need for

fine-grained control and monitoring of workflow execu-
tion, and detailed provenance information. It also facilitates linking the outputs
generated at the output ports of a workflow to the respective inputs, which is nec-
essary for provenance collection. Note that the multiple workflow submissions for
processing are hidden from the end-user, whereas he/she can obtain progress
information about each of the individual tasks such as processing of each input.
When the user starts a new data processing, PM creates a new processing entity
with a number of new submission entities and stores them in the eCAT with
appropriate links to the used application and data entities. Each individual sub-
mission goes through the states illustrated in Fig. 10.3 . The processing entity also
holds a summary of the status of its submissions, which is automatically updated by
database triggers whenever a status is changed. The statuses are refreshed period-
ically by the PM, or manually by the user. The states and the actions performed at
each state are:

Fig. 10.3 Processing state diagram. States are illustrated in ellipses , and final states are illustrated
in gray . For clarity, four actions performed in the “ In Preparation ” state are also illustrated

(adapted from Fig. 4 in Shahand 2014)