Database Reference
In-Depth Information
13.2 Features of Scientific Workflows
13.2.1 The Scientific Workflow Life Cycle
The various phases and steps associated with developing, deploying, and ex-
ecuting scientific workflows comprise the scientific workflow life cycle. The
following phases are largely supported by existing workflow systems using a
wide variety of approaches and techniques (cf. Section 13.4).
Workflow Design and Composition. Development of scientific work-
flows usually starts with gathering requirements from scientists. A specifi-
cation of the desired workflow functionality is then developed, and an ac-
tual workflow is assembled based on this specification. Workflow development
differs from general programming in many ways. Most notably, it usually
amounts to the composition and configuration of a special-purpose workflow
from pre-existing, more general-purpose components, subworkflows, and ser-
vices. Workflow development thus more closely resembles script- and shell-
based programming than conventional application development. During work-
flow composition, the user (a scientist or workflow developer) either creates
a new workflow by modifying an existing one (cf. workflow evolution , Sec-
tion 13.5), or else composes a new workflow from scratch using components
and subworkflows obtained from a repository. In contrast to the business
workflow world, where standards have been developed over the years (e.g.,
most recently WS-BPEL 2.0 13 ), scientific workflow systems tend to use their
own, internal languages and exchange formats (e.g., SCUFL, 14 GPEL, 15 and
MOML, 16 among others). Reasons for this diversity include the wide range
of computation models used in scientific workflows (Section 13.2.3), and the
initial focus of development efforts on scientist-oriented functionality rather
than standardization.
Workflow Resource Planning. Once the workflow description is con-
structed, scientific workflow systems often provide various functions prior to
execution. These functions may include workflow validation (e.g., type check-
ing), resource allocation, scheduling, optimization, parameter binding, and
data staging. Workflow mapping is sometimes used to refer to optimization
and scheduling decisions made during this phase. In particular, during work-
flow design and composition, the target resources to be used for execution are
typically not chosen. Workflow mapping then refers to the process of generat-
ing an executable workflow based on a resource-independent abstract workflow
description. 17 In some cases, the user performs the mapping directly by select-
ing appropriate resources (e.g., in Figure 13.2). In other cases, the workflow
system automatically performs the mapping. In the latter case, users are al-
lowed to construct workflows at a level of abstraction above that of the target
execution environment.
Workflow Execution. Once a workflow is mapped and data has been
staged (selected and made available to the workflow system), the workflow
Search WWH ::




Custom Search