focus

developing scientific software

Scientific Software
as Workflows:
From Discovery to Distribution
David Woollard and Chris A. Mattmann, NASA Jet Propulsion Laboratory
and University of Southern California

Nenad Medvidovic and Yolanda Gil, University of Southern California

I
n the last 30 years, science has undergone a radical transformation. In place of test
Classifying workflow
tubes and optics benches, chemists, physicists, and experimental scientists in a host
environments
of other disciplines are using computer simulation to discover and validate new sci-
according to the ence. This “in silico” experimentation has been fueled by numerous computer sci-
scientific research ence advances, including the ability to archive and distribute massive amounts of data and
phases to which they share hardware resources via the Grid.1
apply is useful for An activity central to in silico experimentation choose.3 One such challenge is that there’s no stan-
scientists interested is orchestration—assembling scientific codes into dard workflow model or fundamental “science” of
an executable system with which to experiment. scientific workflows. At “Challenges of Scientific
in adopting workflow
Orchestration of in silico experiments, much like Workflows,” a recent US National Science Founda-
technology. its closely related cousin in the business world,2 is a tion workshop chaired by one of us, this problem
complex task involving data management (locating was cited as a challenge facing workflow research-
data, reformatting, and so on), managing input pa- ers today.4
rameters for executables, and handling dependen- Thus, requirements for these environments vary
cies between processing elements. significantly among applications. This suggests that
One potentially useful tool for orchestration is we need a taxonomy of workflow environments
workflow environments. At NASA’s Jet Propulsion based on the scientific research activities that they
Laboratory (JPL), for example, scientists and engi- support. Our experience shows that classifying
neers have developed such environments to process these environments according to the phases of in
data from instruments, satellites, and rovers. The silico research to which they apply is useful for sci-
recently landed Phoenix mission to Mars and the entists interested in adopting workflow technology.
Orbiting Carbon Observatory, an Earth-observing Each phase has distinct scientific workflow require-
spectrometer mission set to launch in 2008, both ments. By making scientists aware of these require-
use workflow environments to process raw instru- ments, we intend to better inform their selection of
ment data into scientific products for the external such technologies.
science community.
Despite these early-adopter efforts, scientific Orchestrating experiments
workflow environments haven’t yet reached a large Before discussing the requirements for scientific
user base. Many significant challenges in this do- workflow environments, we must examine the
main remain unaddressed, despite the many sci- workflow’s role in scientific experimentation. By
entific workflow environments from which to framing our discussion with an understanding of

0 74 0 -74 5 9 / 0 8 / $ 2 5 . 0 0 © 2 0 0 8 I E E E July/August 2008 I E E E S o f t w a r e  37


Static
Workflow model
Parses
Executes
Uses Workflow Workflow
Dynamic
engine stage
Accesses
Services (resource discovery, fault registry, provenance registry, etc.)
Dependency Data Process Infrastructure component
Figure 1. A basic
workflow environment. scientists’ current experimentation practices, we in-
The ancillary services tend to clarify the process of evaluating these envi-
encompass many of ronments for a given application.
the non-control-flow
aspects of script-based Scripts and other methods
orchestration. Scientists have solved the problem of orchestra-
tion through various methods, including scientific-
programming environments such as IDL (Interac-
tive Data Language) and Matlab. The predominant
orchestration mechanism, however, is the script.
Scripting languages such as Perl (and more recently
Python) let scientists perform many common or-
chestration tasks, including
■ specifying overarching process control flow,
■ running precompiled executables (via com-
mand line or runtime bindings), and
■ reformatting input and output data.
In common software engineering parlance, these
scripts act as “glue code” between more well-
defined software modules. A script captures the
experiment—its setup (in the form of input param-
eters), procedure (the control flow, or execution
steps), and record of results (formatting and catalog-
ing outputs). So, it’s integral to the overall scientific
effort and is an important artifact in its own right.
However, script-based orchestration has prob-
lems that make workflow modeling an attractive al-
ternative. Scripts are difficult to maintain and easily
obfuscate the developer’s original intention. Lack
of inherent structure or design guidelines makes
script-based orchestration a largely ad hoc process.
Unlike traditional glue code, orchestration in scien-
38 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re
tific workflows can’t be treated as throwaway!
Scientific workflow environments
In scientific workflow environments, workflow
models represent high-level scientific tasks as data-
processing stages (workflow stages) and the data
dependencies between the stages. Workflow envi-
ronments map the stages onto computational (often
Grid-based) resources and plan the data movements
that will satisfy the dependencies. This mapping
is often called a workflow instance or concrete
workflow. A workflow engine steps through the
instance, executing the stages and managing each
stage’s I/O requirements as specified by the model.
This is akin to the control-flow functionality of
script-based orchestration.
As Figure 1 illustrates, a workflow environ-
ment consists of not only the workflow engine but
also ancillary services. These services encompass
many of the non-control-flow aspects of script-
based orchestration, including resource discovery
for accessing data, fault handling, and data prov-
enance cataloging. Although resource discovery
services sometimes handle data-reformatting is-
sues, workflow environments also commonly use
a preprocessing workflow stage to handle format
mismatches.
Characterizing workflow
environment requirements
Although good taxonomies of workflow environ-
ments exist,3,5 each takes a bottom-up approach,
differentiating workflow approaches by the type of
model used (for example, Petri nets versus directed
acyclic graphs) or by the strategy used in allocating
computational resources. Although such character-
ization can benefit software engineers and work-
flow practitioners, we contend that a top-down
taxonomy based on the scientific goals addressed
is more useful to scientists interested in adopting
workflow technologies.
Workflow phases
Like all scientific endeavors, in silico science has
distinctive phases. To take an example from bio-
chemistry, in the early 1920s, John Macleod and
Frederick Banting were the first to successfully iso-
late and extract insulin and are credited with its
discovery. Once scientists refined their understand-
ing of insulin’s structure and properties, they de-
veloped techniques for producing insulin in large
quantities, eventually settling on genetically engi-
neering synthetic insulin in the late 1970s.
Our three phases of in silico science mostly mir-
ror the processes of in vivo and in vitro science:
 1. During discovery, scientists test algorithms and
techniques—that is, they explore the scientific
solution space—and arrive at a process that
yields the desired result. This is what Jeremy
Kepner called the “lone researcher process.”6
2. Production, akin to the chemical-engineering
process that synthesized insulin in large quan-
tities, is the engineering and scientific effort to
reproduce the discovered process on a large
scale.
3. During distribution, scientists share and vali-
date the process’s results and formulate new re-
search goals.
These phases form the basis for the following
classification of workflows.
Discovery workflows. These workflows are rapidly re-
parameterized, letting scientists explore alternatives
quickly to iterate an experiment until they’ve vali-
dated their hypotheses. Discovery workflow envi-
ronments support such dynamic experimentation.
This type of environment’s high-level require-
ments include helping scientists formulate abstract
workflow models and transforming abstract mod-
els into workflow instances.
Production workflows. As in the case of producing
vast quantities of insulin, production workflow en-
vironments focus on repeatability. These environ-
ments should be able to stage remote, high-volume
data sets, catalog results, and log or handle faults.
Unlike discovery workflows, production workflows
must incorporate substantial data management fa-
cilities. Scientists using production workflow en-
vironments care less about the means of abstract
workflow representation than about the ability to
automatically reproduce an experiment.
A production workflow environment’s high-
level requirements include handling the nonorches-
tration aspects of workflow formation such as data-
resource discovery and data-provenance recording.
Such environments should also help scientists con-
vert scientific executables into workflow stages,
including providing means of accessing ancillary
workflow services.
Distribution workflows. Unlike the first two environ-
ments, distribution workflow environments focus
on data retrieval. They use distribution workflows
to combine and reformat data sets and deliver these
sets to scientists.
These environments must support rapid speci-
fication (often using graphical techniques) and re-
mote execution of abstract workflows.
Choosing from the
workflow environment spectrum
It is important to note that many workflow en- Distribution
vironments exhibit the traits of more than one of
the three workflow categories. Additionally, some
workflow
scientific applications we’ve studied fall into more environments
than one category.
Whereas both discovery and distribution work-
must support
flows must help scientists develop abstract work- rapid
flows, distribution workflows emphasize the act of specification
specification rather than the resulting workflow’s
dynamism. Likewise, production and discovery (often using
workflow environments both manage data, al- graphical
though production environments must do so with
much greater autonomy to process large data sets.
techniques)
Rather than present a clean taxonomy of scien- and remote
tific workflow environments for its own sake, we
aim here to help scientists understand their own
execution
scientific workflow requirements, showing how this of abstract
approach can help them choose an environment workflows.
that caters to their scientific goals.
An illustration of the workflow phases
One example of in silico scientific research is bio-
medical-imaging research. Biomedical researchers
use functional magnetic resonance imaging (fMRI)
to provide more accurate images to aid doctors’ di-
agnoses, explore the ties between thought and mea-
surable biological activity, and help biologists ex-
plore brain functions. We can apply our taxonomy
to aspects of fMRI research.
Because fMRI can be used to infer brain activity,
researchers have explored its use in understanding
which brain areas are activated during given tasks,
how aging changes brain activity, and how diseases
can affect brain function. These researchers have
developed algorithms for detection in research set-
tings, including optimization of voxel correlation to
activity and better spatial-temporal resolution. Dis-
covery workflows can support these activities.
Biomedical-imaging researchers also aid doctors
in production-oriented activities. One such activ-
ity is patient imaging to help doctors plan surgery.
fMRI images are taken, corrected, registered, and
used to generate more accurate models of crucial
brain function, which let surgeons more precisely
plan tumor excision.
An example distribution activity is telediagnosis.
Multiple doctors, possibly at different locations, si-
multaneously view the same set of fMRI images to
consult with each other on a diagnosis. This scenario
involves transmitting large sets of images across
both local-area and wide-area networks, including
the Internet. Picture Archiving and Communication
Systems (PACS) often handle these scenarios.
July/August 2008 I E E E S o f t w a r e  39

G1 K1 G2
C-one C-one
Z1 Z2
C-many
X1
D1
C-one
D3
Figure 2. The Wings
system represents
workflows in data- and
execution-independent
structures. Parallel
computations over
data sets (on the top
left) are represented
compactly in the
Wings workflow on the
right. The component
representations
on the bottom left
express whether
the components can
process individual
data sets (for example,
component C-one) or
collections of data (for
example, component
C-many) as input.
ronment. It also uses the Pegasus mapping and
L1 L2
execution system, which submits and monitors
K2 G88 K88 Coll-G Coll-K
workflow executions.7
C-one D1 D2 In addition, Wings has constructs that ex-
press compactly the parallel execution of com-
Z88 NC1
C-one
ponents to concurrently process subsets of a
Y1
given data set.8 It encapsulates codes so that
L3 any execution requirements (such as target ar-
D3 chitectures or software library dependencies) as
Coll-Z L4 well as I/O data set requirements and proper-
F-Y ties are explicitly stated. Code parameters that
D2 D11 D12 D11 can be used to configure the codes (for scientists
D12
these might correspond to different models in
C-many N2
C-many the experiment) are also represented explicitly
D13 and recorded within the workflow representa-
L4 tion. A model of each code is created to express
Data D13 all such requirements, so the codes can be used
Computation F-X
flexibly by the workflow system as workflow
Data flow components. Component classes are created to
capture common properties of alternative codes
and their configurations. The methodology for
Current workflow research designing workflows, encapsulating compo-
Three of our current research projects illustrate our nents, and formalizing metadata properties ap-
taxonomy. In showing how each project addresses pears elsewhere.9
the high-level requirements of a particular class of Figure 2 shows how Wings represents work-
workflow application, we aim to flows in data- and execution-independent struc-
tures. For example, parallel computations over
■ highlight salient research topics in the area and data sets (on the top left) are represented compactly
■ illustrate our taxonomy with real-world work- in the Wings workflow on the right. The compo-
flow environments. nent representations on the bottom left express
whether the components can process individual
Discovery workflow environment: Wings data sets (for example, component C-one) or col-
Formulation of discovery workflows is an act of ex- lections of data (for example, component C-many)
ploration for scientists, whether they’re systemati- as input. Wings exploits these constraints and rep-
cally trying alternatives or haphazardly looking for resents the parallel computations as a collection
a surprising result. To formulate useful workflows, of components (for example, node NC1) that are
scientists try different combinations and configura- expanded dynamically into individual executable
tions of components and use new data sets or com- jobs depending on the size of the data set bound
ponents.5 An environment for formulation of dis- to the input variables (for example, to the variable
covery workflows must Coll-G). For each of the new data products (for ex-
ample, those bound to Coll-Z), Wings generates
■ help users find components, workflows, and metadata descriptions based on the metadata of
data sets on the basis of desired characteristics the original data sets and the component models.
or functions; Using these high-level and semantically rich
■ validate the newly created workflows with re- representations, Wings can reason about compo-
spect to the requirements and constraints of nent and data set properties to help users compose
both the components and data sets; and and validate workflows. Wings also uses these
■ facilitate the evolution and versioning of previ- representations to generate the details that Pega-
ously created workflows. sus needs to

One such environment is Wings.7,8 To repre-
sent workflows, Wings employs semantic meta-
data properties of components and data sets.
Wings uses workflow representations that are
expressed independently of the execution envi-
■ map the workflows to the execution environ-
ment and
■ generate metadata descriptions of new data sets
that result from workflow execution and that
help track provenance of new data products.7

40 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

 Workflow stage execution request/reply
Workflow engine
Data discovery
Event queue Invoking connector
Provenance registry
Event queue Module interface
Fault registry Event queue
Event queue Thread pool
Workflow environment
Asynchronous call Synchronous request/reply
To facilitate workflow evolution, Wings expects
each workflow to have its own namespace and on-
tology definitions. All workflows are represented
in the Web Ontology Language (OWL) and follow
conventions of Web markup languages in import-
ing ontologies and namespaces. Each ontology and
namespace has a unique identifier and is never mod-
ified or deleted; new versions are given new identifi-
ers. Related workflows can import shared ontology
definitions and refer to common namespaces. We’re
exploring extensions to these capabilities for more
manageable version tracking, particularly in collab-
orative settings.
Production workflow environment: SWSA
As we mentioned before, production workflow en-
vironments incorporate significant data manage-
ment technology to reproduce scientific workflows
on very large data sets. Production environments
must not only handle the workflow’s scientific
requirements but also manage the significant en-
gineering challenges of automatic processing of
large data sets.
Owing to the demands of automatic processing,
a particular challenge in production workflow en-
vironments is integration of scientific codes. Locat-
ing remote data sets, handling faults appropriately,
cataloging large volumes of data produced by the
system, and managing complex resource mappings
of workflow stages onto Grid and multigrid envi-
ronments require scientific workflow stages to ac-
cess a host of ancillary workflow services.
The Scientific Workflow Software Architec-
ture (SWSA) project at JPL and the University of
Southern California (USC) aims to provide a soft-
ware architecture for workflow stages that clearly
differentiates scientific code from the workflow
stage’s engineering aspects. SWSA breaks up the
Exogenous connector
Custom Handler Logic
handle(Event control){
data = dataService.get(control.reqData);
processEvent = new Event(control,data); Module
result = module.process(processEvent);
provenanceService.register(result);
faultService.register(result.exitCode);
exoConn.dispatch(result);
Kernel
} Architected
workflow
Representative module
stage
Component Connector
Figure 3. An
scientific algorithm into components, isolating architecture for
communication with workflow services to spe- scientific-workflow
cialized software connectors. This separation of stages, including
concerns lets scientists and software engineers connectors to workflow
converse about workflow stage design without services. Users can
having to be experts in both science and software specify the necessary
engineering.10 communication between
As the first step of creating the software archi- the workflow stage
tecture, SWSA decomposes scientific code into and ancillary workflow
scientific kernels. These kernels, like code kernels services in custom
in high-performance computing, are code snip- handlers that are
pets that implement a single scientific concept. isolated to the invoking
In a graph-theoretic sense, a kernel is a portion connector for each
of the call dominance tree for the source code’s module.
basic blocks that has a single source and a single
sink—it has internal scope and single entry and
exit points. To identify these kernels, users need to
analyze the original source code’s basic block call
graph to identify calls made to execute each kernel
(its control) and the data dependencies between
each kernel (its data flow). The current SWSA ap-
proach requires manual decomposition; we’re ex-
ploring semiautomatic approaches based on soft-
ware architecture recovery.
In the second step, SWSA wraps these kernels in
a component interface, creating modules (see Figure
3). It implements the original program’s control and
data flow in a hierarchically composed exogenous
connector.11 Finally, an invoking connector makes
calls to ancillary workflow services. An engineer
can manage the scientific workflow’s engineering
requirements through custom handlers that access
services such as data discovery, data provenance
registries, and fault registries.
Distribution workflow environment: OODT
Once a production workflow has generated the
necessary scientific information, that information
July/August 2008 I E E E S o f t w a r e  41

Production workflow
Data Movement Data
Data access technology
subsetting distribution
selection
Science
community
Distribution workflow
Figure 4. The four
canonical stages of must be appropriately disseminated to the scientific
distribution workflows. community to effectively communicate the results.
Data is accessed, it’s As Daniel Crichton and his colleagues noted, as the
(potentially) subset, an study sample increases, so does the chance of dis-
appropriate movement covery.12 In the Internet age, scientists have begun
technology is selected, leaning on Internet technologies and large-scale
and then the data is data movement capabilities to exploit this principle,
ultimately disseminated sharing their raw science data and analyses with
to the scientific colleagues throughout the world.
community. To move data to science users, distribution
workflows leverage data movement technologies
and data packaging (or repackaging) technologies.
This process is underpinned by distribution scenar-
ios specifying a data distribution’s important prop-
erties (for example, the total volume to be delivered,
the number of delivery intervals, or the number of
users to send data to). As Figure 4 illustrates, dis-
tribution workflows typically have four distinct
stages:
1. Data access. The scientific information pro-
duced by a production workflow is accessed (for
example, from a database management system,
a file system, or some other repository).
2. Data subsetting. If necessary, the data is pack-
aged, repackaged, or “subsetted” (broken down
into subsets) for its external science customers.
3. Movement technology selection. An appropri-
ate data movement technology (for example,
FTP, HTTP, or Bittorrent) is selected.
4. Data distribution. The data is transferred to the
science community.
As an illustration of this workflow’s complexity,
consider this representative use case:
More than 100 Gbytes of Planetary Data
System (PDS) Spice (Spacecraft Planet Instru-
ment Camera Matrix Events) kernel data
sets (describing planetary-mission navigation
information) and PDS data sets must be sub-
setted and sent across the wide-area network
(WAN) from the PDS engineering node at
JPL to the European Space Agency (ESA)
and from JPL across the local-area network
42 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re
(LAN) to the (local) PDS Navigation and
Ancillary Information Facility (NAIF) node.
The data must be delivered securely (using
port-based, firewall pass-through) to over 100
different engineering analysts and to project
managers, totaling 10 distinct types of users.
The users would like the data delivered in no
more than 1,000 intervals. (An interval is a
discrete data transfer event.) Owing to the un-
derlying network capacities of the dedicated
LAN to the NAIF and the WAN to the ESA,
the data must be delivered in 1 Mbyte to 1
Gbyte chunks during each interval. The data
must reach its destination quickly in both
cases (owing to the information’s sensitivity
and the urgency with which it’s needed), so
scalability and efficiency are the most desired
properties of the transfer.
Clearly, such scenarios involve disseminating
large amounts of information from data produc-
ers (for example, the PDS engineering node) to data
consumers (for example, ESA). Several emerging
large-scale data dissemination technologies purport
to efficiently transfer data from producers to con-
sumers and to satisfy requirements such as in our
example scenario.
In our experience, however, some technologies
are more amenable to different classes of distribu-
tion scenarios than others. For example, Grid1
technologies (such as GridFTP) are particularly
well suited to handle fast, reliable, highly paral-
lel data transfer over the public Internet. How-
ever, this benefit comes at the expense of running
heavyweight infrastructure (for example, security
trust authorities, Web servers, and metadata cata-
log services). On the other hand, peer-to-peer tech-
nologies, such as Bittorrent, are inherently more
lightweight than Grid technologies and as fast as
these technologies, but they’re less reliable and de-
pendable. Distribution workflows must be able to
decide, either with user feedback or autonomously,
which appropriate data movement technology and
dissemination pattern (for example, peer-to-peer or
client-server) to employ to satisfy use cases such as
the PDS data movement problem.
Our recent research has investigated how to
construct distribution workflows that employ the
appropriate technology for a given use case, in the
context of JPL’s Object Oriented Data Technology
(OODT) data distribution framework.13 OODT
provides services for packaging, repackaging, sub-
setting, and delivering large amounts of informa-
tion, across heterogeneous organizational struc-
tures, to users around the world.
In addition, our recent research at USC has led
to the construction of the Data-Intensive Software
Connectors (Disco) decision-making framework.14
Disco is a software extension to OODT that uses
architectural information and data distribution
metadata to autonomously decide the appropriate
data movement technology to employ for a distri-
bution scenario or class of scenarios. In our expe-
rience, the combination of a data movement infra-
structure and a decision-making framework that
can choose the underlying dissemination pattern
and technology to satisfy scenario requirements is
essential to successfully implement and design dis-
tribution workflows.
W
e plan to continue fundamental re-
search into the science of scientific
workflow technology. This includes de-
veloping more rigorous workflow models that can
help bridge the discovery and production workflow
environments.
We’ll also continue to develop approaches to
ease adoption of workflow technology, including
improved integration of legacy scientific codes, bet-
ter methodologies for adopting workflow model-
ing over script-based orchestration, and decision-
making frameworks for delivering the resulting
data products to the scientific community.
Acknowledgments
We gratefully acknowledge support from the US Na-
tional Science Foundation under grant CCF-0725332.
Some research described in this article was conduct-
ed at the Jet Propulsion Laboratory, managed by the
California Institute of Technology under a contract
with the US National Aeronautics and Space Admin-
istration.
References
1. I. Foster et al., The Physiology of the Grid: An Open
Grid Services Architecture for Distributed Systems
Integration, Globus Alliance, 2002, www.globus.org/
alliance/publications/papers/ogsa.pdf.
2. C. Peltz, “Web Services Orchestration and Choreogra-
phy,” Computer, vol. 36, no. 10, 2003, pp. 46–52.
3. J. Yu and R. Buyya, “A Taxonomy of Scientific Work-
flow Systems for Grid Computing,” ACM S igmod Rec­­-
ord, vol. 34, no. 3, 2005, pp. 44–49, www.sigmod.org/
sigmod/record/issues/0509/p44-special-sw-section-7.pdf.
4. Y. Gil et al., “Examining the Challenges of Scientific
Workflows,” Computer, vol. 40, no. 12, 2007, pp.
24–32.
5. Y. Gil, “Workflow Composition: Semantic Repre-
sentations for Flexible Automation,” Workflows for
E-science, D. Gannon et al., eds., Springer, 2006, pp.
244–257.
6. J. Kepner, “HPC Productivity: An Overarching View,”
Int’l J. High-Performance Computing Applications,
vol. 18, no. 4, 2003, pp. 393–397.
7. J. Kim et al., “Provenance Trails in the Wings/Pegasus
Workflow System,” to be published in Concurrency and
Computation: Practice and Experience, vol. 20, no. 5,
About the Authors
David Woollard is a cognizant design engineer at NASA’s Jet Propulsion Laboratory
and a third-year PhD candidate at the University of Southern California. He’s also a primary
developer on JPL’s Object Oriented Data Technology project. His research interest is software
architectural support for scientific computing, specifically support for integrating legacy
sci­entific code into workflow environments. Woollard received his MS in computer science
from USC. He’s a member of the IEEE. Contact him at woollard@jpl.nasa.gov.
Nenad Medvidovic is an associate professor in the University of Southern Califor­nia’s
Computer Science Department. His work focuses on software architecture modeling and
analysis; middleware facilities for architectural implementation; product-line architectures;
architectural styles; and architecture-level support for software development in highly dis-
tributed, mobile, resource-constrained, and embedded-computing environments. Medvidovic
received his PhD in information and computer science from the University of California, Irvine.
He’s a member of the ACM and IEEE Computer Society. Contact him at neno@usc.edu.
Yolanda Gil is the associate division director for research in the Intelligent Systems
Division at the University of Southern California’s Information Sciences Institute and a
research associate professor in USC’s Computer Science Department. Her research interests
include intelligent interfaces for knowledge-rich problem solving and scientific workflows
in distributed environments. Gil received her PhD in computer science from Carnegie Mellon
University. Contact her at gil@isi.edu.
Chris A. Mattmann is a member of key staff at NASA’s Jet Propulsion Laboratory,
working on instrument and science data systems on various earth science missions and
informatics tasks. His research interests are primarily software architecture and large-
scale data-intensive systems. Mattmann received his PhD in computer science from the
University of Southern California. He’s a member of the IEEE. Contact him at mattmann@
jpl.nasa.gov.
2008, pp. 587–597.
8. Y. Gil et al., “Wings for Pegasus: Creating Large-Scale
Scientific Applications Using Semantic Representations
of Computational Workflows,” Proc. 19th Ann’l Conf.
Innovative Applications of Artificial Intelligence (IAAI
07), AAAI Press, 2007, pp. 1767–1774.
9. Y. Gil, P.A. Gonzalez-Calero, and E. Deelman, “On
the Black Art of Designing Computational Workflows,”
Proc. 2nd Workshop Workflows in Support of Large-
Scale Science (Works 07), ACM Press, 2007, pp. 53–62.
10. D. Woollard, Supporting In Silico Experimentation
via Software Architecture, tech. report USC-CSSE-
2008-813, Center for Systems and Software Eng., Univ.
of Southern Calif., 2008, http://sunset.usc.edu/csse/
TECHRPTS.
11. K.-K. Lau, M. Ornaghi, and Z.Wang, “A Software
Component Model and Its Preliminary Formalisation,”
Proc. 4th Int’l Symp. Formal Methods for Components
and Objects, Springer, 2006, pp. 1–21.
12. D. Crichton et al., “A Distributed Information Services
Architecture to Support Biomarker Discovery in Early De­
tection of Cancer,” Proc. 2nd IEEE Int’l Conf. E-science
and Grid Computing, IEEE CS Press, 2006, p. 44.
13. C. Mattmann et al., “A Software Architecture-Based
Framework for Highly Distributed and Data Inten-
sive Scientific Applications,” Proc. 28th Int’l Conf.
Software Eng. (ICSE 06), IEEE CS Press, 2006, pp.
721–730.
14. C. Mattmann et al., “Software Connector Classifica-
tion and Selection for Data-Intensive Systems,” Proc.
ICSE 2007 Workshop Incorporating COTS Software
into Software Systems: Tools and Techniques (Iwicss),
IEEE CS Press, 2007, p. 4.
July/August 2008 I E E E S o f t w a r e  43