Component Architectures and the LSA

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. Partly this 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 market.

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 system itself.
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 basis.

Next page: the problem domain, describing the application problems and methods of the LSA.

bramley@cs.indiana.edu

Last updated: Tue Jan 26 12:26:47 1999