Databases and Systems

287
sequence-assembly Worker in our cDNA-sequencing example might be reused in a
genomic sequencing project. It is also reasonable to imagine that two or more
different Workers might be implemented for the same job using different
components, e.g., we might develop one sequence-assembly Worker based on phrap
[19] and another based on TIGR Assembler [20]. It is also reasonable to expect that
the same component might be used for several purposes, e.g., we might use a fast
sequence alignment program, such as FASTA [21] or crossmatch [22], for both
vector-stripping and contamination-checking. For these reasons, it makes sense to
organize the collection of Workers as a class library with well-defined interfaces that
are separate from their implementations, and to allow Workers to call each other. In
the long run, success with our method (and probably any other modular approach to
LIMS construction) depends on the accumulation of a well-designed library of good
Workers.
After Workers are developed, what remains is to connect them together into a
complete workflow. There are two main tasks: a Step must be created for each
Worker, and Routers must be defined to connect the Steps together. The main work
in defining a Step is to determine the mapping between the field-names used by the
Worker and those used by the workflow as a whole. (These field-names may be
different since Workers are written for reuse). Routers are generally straightforward
for success-cases, but can be tricky for failure-cases; often, in the early days of a
project, all failures are sent to a catch-all Worker that reports the event to laboratory
supervisors.
Let us apply these ideas to our running example. We will model the database as
suggested in the previous section, i.e., with two kinds of Materials, namely,
sequence-reads and sequence-assemblies. Since a given LabFlow can operate on
only one kind of Material, the overall system will need two LabFlows. We will only
describe the first. The sequence-read LabFlow needs Workers for robot-control,
base-calling, vector-clipping, quality-screening, and review by laboratory personnel.
Robot-control software generally comes with the machine and cannot be modified
by the customer; often the software runs on a dedicated computer, and can only be
operated by a person entering commands directly at that computer. The Worker, in
such cases, helps the human operator coordinate the robot with the rest of the system.
Assume for purposes of the example, that the outputs of the robotic procedure are (i)
a collection of plated clones, and (ii) a collection of plated sequencing-templates
derived from those clones, and that these plates are bar-coded. The most important
coordination task is to record the bar-codes of the plates in such a way that the each
clone-plate is associated with the corresponding template-plate (so that subsequent
sequence data can be associated with the correct clone). The Worker software for
doing this might be no more than a Web-based program that accepts bar-codes
(entered by the operator using a bar-code wand) two-at-a-time, and passes each pair
back to the Step.
Next comes base-calling. Assume that we use phred [23] for this purpose, and
that we wish to run phred in real-time on the data stream generated by the sequencing