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

for those jobs, but these settings won ' t be enforced if the job ' is resource is con-

figured, for example, for PBS (Henderson 1995).
Job con

gurations regarding the middleware types are not coherent; in some
cases the resource requires us to specify the concrete computational resource where
the job will be submitted (for instance, Globus Toolkit). Some others just need a
broker server to be de ned (e.g., gLite). On the other hand, the application itself

influences the dif culty of the con guration, too. For example, if the algorithm is an

MPI application, we need to de ne this property and then we must set the required

number of processors for the execution as well.
In theory, the most complicated case is if the job refers to a workflow. To
achieve this scenario is quite simple: only the required workflow is link should be

selected for the job. We remark that only those workflows can be embedded that are
inherited from a template. Then, as shown in Fig. 3.1 d, the input and output ports of
the embedded workflow must be connected with the container job

'

s input and
output ports, respectively, and to establish the information channel between the
workflows.
The bottom of Fig. 3.4 shows possibilities of port con

'

gurations are with respect

“ ”

to their main property. They can be set to be input or output ports.

According to this setting, several properties can be de

ordering

ned related to the port, for

example, the internal input/output file name required by the appli-

cation, or needed to be generated by the application), the destination of the file in
general (local or remote), and so on. To do all of these con

file name (the

guration steps, the WS-

PGRADE user interface provides a handy con guration panel.

3.5.3 Execution Time Work fl ow Instance View

—

After designing a concrete workflow, it can be submitted for interpretation to the
gUSE Workflow Interpreter (WFI). The same concrete workflow can be submitted
several times in parallel, generating multiple instances of the con

gured workflow.
Workflow instances reflect the enactment of the concrete workflow guration

at runtime regarding the number of job instances generated dynamically from PS
nodes, and their execution states on remote resources mapped to status information,
such as

' s con

. Figure 3.5 illustrates the complete
state diagram of the execution of a workflow instance, where the lines represent the
actions performed (lines with circles denote automatic status changes), and rect-
angles represent the certain states.
By de

“ submitted ” , “ running ” or “ “finished” ”

nition workflows stay in the “ init ” state. If the “ delete ” action is invoked,

' “ ”

the workflow , triggering its deletion automatically, and the

process ends. Another option is when the

is state is set to deleted

“ ”

submit action triggers, changing the

“ ”

state to , then, supposing that DCI-Bridge has submitted the job cor-

rectly, the state will be changed to

submitted

state several auto-
mated status changes are possible, depending on whether the con

“ running ” . In the “ running ”

guration is

correct. Finally, the state can be changed to “ “finished” ” or “ error ” . The “ Delete ”