Databases and Systems

286
LabFlow Workflow Management System
LabFlow provides a Perl5 object-oriented framework for describing laboratory (or
other) workflows, The most significant classes in this framework are Worker, Step,
and Router. Workers encapsulate the components which do the computational work
of the information system. The Worker class defines interfaces that allow arbitrary
programs to be connected to the workflow. Steps in LabFlow are analogous to those
in LabBase, but whereas in LabBase a Step merely records data, in LabFlow a Step
embodies the computation that generates the data, and the “glue” that connects the
computation to the rest of the information system. (The LabBase and LabFlow Step
concepts are so similar that we find it natural to use the same term for both). Each
Step has two parts: an input queue (actually a State) containing Materials that are
waiting for the Step to be performed, and a Worker which does the actually
computation. Technically, a Step need not contain a Worker or may employ multiple
Workers, but we will not discuss these complications. Routers connect Steps together
by examining the answer produced by the Step (technically, the answer
produced by the Step’s Worker) and deciding where to send the Material for
subsequent processing. The LabFlow framework also includes classes for Materials
and States which are analogous to those in LabBase, and a LabFlow class to
represent entire workflows. LabFlow contains an “execution engine” that runs a
workflow by invoking its Step repeatedly. A LabFlow can be packaged as a subworkflow
and used subroutine-style within another workflow. A key limitation in our
current software is that a given LabFlow operates on a single kind of Material.
The system uses States to keep track of “where” each Material is in a LabFlow.
We have already mentioned that States are used to represent the input queues of each
Step. In addition, each Step has three other built-in States. One of these holds
Materials that are actively being processed by the Step. A second holds Materials for
which the Step (or its Worker) discovered a problem that contraindicates further
progress, e.g., the Step checking for E. coli contamination would place contaminated
Materials in this State. The final built-in State holds Materials that were being
processed by the Step when its Worker or its component crashed; sometimes this is
just a coincidence, but often it reflects a bug in the Worker or component software.
In addition to these built-in States, the workflow designer is responsible for defining
States that represent successful completions of the workflow. The designer may also
define additional failure States, and States that represent points where the protocol
“pauses”.
The biggest job in creating a LIMS is to develop or acquire the components since
these do the actual computational work of the project. The next biggest job is todevelop
the Workers since these must accommodate the idiosyncrasies of the
components. A typical system contains many Workers (dozens or more), and new
ones must be developed as the computational needs of the project change. It is
reasonable to expect that Workers may be reused in different applications, e.g., the