Information Technology Reference
In-Depth Information
A BPEL process is
control-flow-driven
because it contains full
pledged control primitives to describe the complex business logic. In
contrast, a Taverna workflow is
dataflow-driven
, that is, a workflow
graph describes data dependencies instead of control dependencies.
Therefore, a BPEL workflow is executed according to the control
structure, while a Taverna workflow's tasks are activated when data,
rather than control, reach them. In a scientific domain, such a dataflow
paradigm has the advantage that system-level issues such as task
scheduling and parallelization are completely transparent to designers,
as parallelism is specified implicitly through data dependencies.
This dataflow versus control-flow difference also leads to the
distinction in how parallelism is handled in BPEL and Taverna. In
BPEL, a set of parallel tasks need to be explicitly specified using the
<
Flow
>
or
<
ForEach
>
constructs. In contrast, a scientific workflow
often needs to deal with large datasets that are expressed using collec-
tion data structure such as arrays or lists. The Taverna dataflow model
permits the execution of a task on each element of an input list, without
explicitly adding a parallel construct. Since data parallelism in a
scientific workflow can be overwhelming, this feature, referred to as
implicit iteration
of tasks over lists, can not only make the workflow
compact but also exploit system-level concurrency and pipelined
execution.
In addition, in a business workflow,
transactional property
is
critical to the correctness of a business transaction. In case of failure,
the system has to roll back to a consistent state. BPEL provides a rich set
of primitives to keep the process itself as well as participant services in a
consistent state upon process failure. In BPEL, faults are caught by fault
handlers and processed there with some compensation for the work
already accomplished, to keep the business logic in a consistent state.
Taverna embodies a functional programming style, which assumes side
effect-freeness of involving functions (i.e., activities). With this assump-
tion, Taverna handles failures in a straightforward way, that is, it asks the
failed activities to retry (or try a substitute). This assumption is reasonable
because a large majority of services, for example, most caGrid services,
are stateless and side effect-free, being concerned simply with either data
querying or data processing. If such services fail to yield a result, Taverna
can simply retry them or resort to a substitute.
Table 7.1 summarizes the comparison results between BPEL and
Taverna. Some examples and additional discussions can be found in
