An important new paradigm in software engineering has been
the emergence of distributed component architectures.
Here components are reusable building blocks for
software systems. Such systems for composing components
include Microsoft's ActiveX/DCOM and Sun's
JavaBeans and JavaStudio. Conceptually, a user has a palette
of components from which to choose, and can compose or
wire them together to create complete applications. Mechanisms
are provided for defining new components which follow standards
specifying interfaces, methods by which external codes
can interact with the component. A useful model is that of a
software integrated circuit; as a hardware IC has a specified set
of pins that allow it to be connected with other IC's without
requiring details of internal representations or methods, software
IC's rely on published interfaces.
Distinction from Other Software Buidling Blocks
Components differ significantly from standard software pieces
such as subroutines, libraries, or objects in at least three ways.
Component composition involves modifying and linking binaries,
rather than source code which must then be re-compiled.
More generally, components are live objects with an active state.
They interact on a peer-to-peer basis; no component is
designated as a "main" program which controls the others. More
generally, component systems do not have a hierarchy of control,
although typically a user can group several components to create
a new, larger component.
Component systems are a natural environment for multi-language
and heterogeneous computing systems, unlike object-oriented systems
built using C++ or Smalltalk. In fact a "component" can be
more than a software chunk; it can be a remotely contolled
instrument, a large database, or a specialized signal processor.
Component Systems and Scientific Computing
Although component architectures have revolutionized the desktop
business application computing environment, they have made few inroads
in problem-solving environments for computational science and engineering.
is because the sheer size of data which typical computational components
need to exchange; where a GUI system built from Java Beans may require
a few hundred bytes to be sent from one component to another,
hundreds of Mbytes are common in scientific computing. Another
reason is the variety of data types exchanged in
scientific computing. Possibly the most important reason is
economic; devising a component architecture for business information
systems can have an immediate and profitable return, while scientific
and engineering computations are a small part of the computing
The LSA As a Component System
The LSA is a scientific computing component system implementing a
problem-solving environment. It is an environment for
examining and developing solution strategies for large-scale sparse
linear systems of equations. It includes an extensible palette of
many standard codes for manipulating and solving the linear systems,
and a graphical user control system which presents
a user with a "canvas" on which to compose components. Each component
can be started on any networked computer. This article presents
the purpose and design ideas behind the LSA and its architecture,
which is designed to be reusable for problem domains beyond
the solution of linear systems.
LSA Implications for Component Systems
Although the LSA project is still evolving, it has already
revealed some important design issues for component
systems in scientific computing:
Since they lack the tight
integration (or monolithic character) of most PSEs, it is
critical to provide an information
subsystem which collects summary results
from the distributed components and presents them to a user in
a practical form.
This information subsystem must also provide
information about the state and performance of the component
A variety of communication
subsystems is needed, ranging from graphical cues for the user
interface to high-performance communications paths between components.
For the system to be usable and extensible
access must be provided to both procedural and
object-oriented programmers to add components. Even though the
overall component framework is probably best implemented using
object-oriented technology and concepts, programmers using
imperative languages need to be able to use and
add to a practical scientific computing component system.
Different component frameworks must be able to interact the
way that components do within a framework: on a peer-to-peer
Next page: the problem domain,
describing the application problems and methods of the LSA.