A biologist composing an “in silico” experiment by dragging blocks onto a canvas draws a graph of data dependencies; the engine that runs it on a computational grid instead orchestrates a set of web services according to a control-flow language. Making the two match — the diagram and the orchestration — is the central problem of a portal that wants to make bioinformatics accessible to people who do not write code.

Problem

A typical bioinformatics pipeline is a sequence of command-line tools, each with its own input and output format. A sequence is searched in a data bank (GeneBank), several sequences are aligned with ClustalW, primers are designed with Primer3, specificity is checked with BLAST. Each step is a program in its own right, written in different periods, with its own conventions. ClustalW is described in the 1994 paper by Thompson, Higgins and Gibson; Primer3, by Rozen and Skaletsky (2000), is distributed under the GPL; BLAST goes back to the algorithm of Altschul and colleagues from 1990. None of the three was designed to be orchestrated by a third party.

The lab researcher, however, does not want to paste one program’s output into the next program’s input by hand, nor to write a script that does it. They want to draw the pipeline and press “run”. Between these two wishes there are two jumps: from the drawing to an executable representation, and from that representation to the computational grid that actually runs it.

Architecture

The first jump is a compilation. The visual editor exposes a palette of operators — the pipeline steps as configurable macroblocks — and a canvas on which to connect them. What the user builds is a graph: nodes representing services, edges representing the passing of data. This graph is automatically translated into WS-BPEL (Web Services Business Process Execution Language), which became an OASIS Standard in version 2.0 on 11 April 2007. The BPEL document so generated describes a process that invokes, in order and with the correct dependencies, the web services wrapping ClustalW, Primer3, BLAST and the other tools.

The second jump is execution. The BPEL process is handed to an orchestration engine — in the case of ESCOGITARE the Active BPEL Engine — which talks to the underlying computational grid, built on Globus Toolkit (version 4.0, from April 2005, sits entirely on the WSRF web-service architecture) and described by the MDS information service. The engine knows nothing about bioinformatics: it sees <invoke>, <receive>, <assign> activities and executes them. All the domain knowledge sits upstream, in the palette’s macroblocks and in the compiler that turns them into BPEL.

The portal wrapping all this is the layer the user reaches from the browser: it publishes the project’s content, collects the workflows shared by the community and makes them available to anyone who wants to reuse them. A concrete applied form of this architecture — the visual editor, the CMS and the integration with the ISTI-CNR grid — is described in the project published by noze: https://www.noze.it/en/projects/escogitare/.

The critical point

The point where the translation becomes hard is the distance between the two models of computation. What the biologist draws is a dataflow: blocks fire when their input data is ready, and the order of execution is implicit in the dependency graph. WS-BPEL, on the other hand, was born to orchestrate business processes and is a control-flow language: order is explicit, expressed by constructs such as <sequence>, <flow>, <while>, and the correlation between messages must be declared. The two semantics do not coincide.

Compiling a dataflow into BPEL means bridging this distance automatically: deriving an explicit control structure from a data-dependency graph, deciding which branches can proceed in parallel inside a <flow> and which must stay in <sequence>, handling the format adaptation between one service and the next (in ESCOGITARE there are dedicated adapter blocks, such as the one carrying the output of a sequence search into Primer3’s input). The same problem is discussed, in the same years, by environments such as Sedna, which generates BPEL from a visual modelling of scientific workflows, and in the comparison between Taverna — natively dataflow — and BPEL as engines for grid workflows. The recurring conclusion is that the translation is possible but not free: every non-trivial BPEL construct that the graph does not express directly must be inferred, and that inference is the piece of engineering that decides whether the editor stays usable or not.

Implications

The design consequence is that the editor’s simplicity is a constraint, not a bonus. If the goal is to let biologists who do not write code compose pipelines, then the compiler towards BPEL must absorb all the complexity the user must not see: credential handling on the grid, job duration, type adaptation, the mapping of parallelism. The closer the visual model stays to the way a researcher thinks about the experiment — a chain of transformations on data — the more work falls on the translation layer.

There is also an effect on reuse. A workflow expressed as a graph and then compiled into BPEL is a shareable artefact: it is published, copied, modified. The community of distributed labs exchanging it does not need to know how that graph becomes an executable process; it is enough that the translation be deterministic and that the same drawing produce the same execution. The reproducibility of the experiment therefore depends also on the stability of the compiler, not only on the correctness of the individual tools.

Limits

The automatic translation covers the workflows that can be expressed as graphs of well-typed services; what remains outside are the cases where the scientific logic requires control flow that the visual model does not represent — data-dependent iteration, runtime decisions, fine-grained handling of a single tool’s errors. BPEL is expressive on these, but the visual editor tends not to be, and the choice to keep it simple cuts out precisely the hard part.

The question of the coupling to the stack also stays open. The generated process presupposes Active BPEL, Globus 4 and the set of services wrapping the bioinformatics tools. Moving those workflows to another grid, or to another generation of middleware, means re-targeting the translation onto another backend: the graph drawn by the biologist survives, the BPEL derived from it much less so. The real portability lies in the visual model and its meaning, not in the code that runs it today.

Cover image: ESCOGITARE project image (ISTI-CNR / noze).