\setcounter{chapter}{0}
\setcounter{equation}{0}
\setcounter{figure}{0}

\chapter{Introduction}

In this introductory chapter we first outline
the fundamental questions
in parallel computing that motivate this thesis work
and identify the key research issues
to be studied. We discuss the role software integration
plays in solving real-world applications on high-performance parallel and
distributed systems. 
Viewing software integration as essentially part of the conceptual problem-solving process and environment in mapping meta-problems of complex
applications onto meta-computers that consist of disparate parallel and distributed
computing elements, we  
focus our discussion on basic features and
software engineering requirements found in the two complex systems.

\section{Problem Definition}
Today's parallel software systems comprise islands of automation.
All software components perform some limited range of useful
functions, but components usually do not interoperate effectively.
Although the driving force behind the adaption of parallel computers
is the performance requirement, most real-world applications
demand a sophisticated software system that provides both high performance
and versatility. For example, parallel software systems
are expected to have graphical user interfaces to incorporate complex
data types, to require the use of multiple
programming models, paradigms and parallelisms, 
and to have integrated database capability as well as many other
particular functionalities. A general parallel software system is a toolbox
that can be customized and optimized for particular application needs.
On the other hand, parallel computers are very specialized
systems. Different vendors usually develop different
software. One of the major problems in parallel software
engineering is how to provide software interoperability and system
customization beyond the single-platform capability.
Software integration, i.e., how to combine or ``glue'' various pre-existing components
into an integrated environment, is the main topic of this work.

As an effective parallel computation model, dataflow has been widely
studied in computer architecture and in compiler and programming languages, yet
little previous work has been done on using a dataflow model as an integration framework. Our major 
approach to software integration is built on a dataflow execution model.
Some fundamental questions to be studied
in this thesis include:
\begin{enumerate}
\item
Can a coarse-grained dataflow programming
paradigm be applied to a software integration model? If the answer
is ``yes,'' what are the major benefits and drawbacks as compared to other
approaches? 

\item
What are the key issues in building a dataflow-based integration system?
More specifically, what applications are best suited to the dataflow
integration model? 

\item
Can the dataflow model provide a complete coordination
framework with which to integrate coarse-grained task-parallelism and
fine-grained data-parallelism?
\end{enumerate}

Parallel processing of an application requires 
partitioning and allocating the underlying
computation for the targeted architecture. 
Parallel processing provides many 
alternative solutions to a specific problem. Determining the
efficiency of such solutions in a reliable way is a crucial goal. 
Current methodologies for parallel computing are 
too complex and too specialized to be accessible
to most engineers and scientists. 
A major areas that requires
software integration is a Problem-Solving Environment
(PSE), an integrated collection of software tools that facilitates
problem-solving in some domain.
A PSE must hide most or all of the
considerations of load balancing, parallelization 
of algorithms, distributed memory, message passing, etc. 
Based on extensive case studies in building several
application-specific PSE's,
this thesis intends to answer the following questions
about building a general PSE on HPDC systems:
Is the proposed dataflow-based software integration framework
sufficient for a general PSE?
What are the component technology and 
parallel software integration requirements for a PSE in terms
of functionality and performance?
Can the integration of Web-based, coarse-grained, distributed computing and 
fine-grained parallel programming languages provide a complete PSE solution
to general HPDC applications?

\section{Meta-Problems and Meta-Computers}

Meta-problems can be defined as complex problems that require significant 
computational power and space not possible 
on a conventional uniprocessor computer or single supercomputer within 
the required time.  In other words, meta-problems are a class of 
applications to be solved on high-performance parallel and distributed 
computing systems.  Grand Challenge problems, for example, which are complex 
problems of national societal importance that demand more resources 
than can be provided by any one
conventional computer, and National Challenge applications are 
among the meta-problems. 
While this definition may be fuzzy in terms of ``big'' and ``complex'' 
characteristics, they share some common features:

\begin{enumerate}

\item
{\bf Complex problem structures and domain}

In terms of problem structures and domain knowledge, meta-problems
are usually nonuniform, irregular, and heterogeneous. 
In most cases there is little or no structured representation at the topmost level
and their components are loosely coupled with each other, although within a subdomain
the structure may be well defined. It is usually anticipated that some
parts of a meta-problem may be highly sequential, while others are parallel. 
Most meta-problems are multidisciplinary or interdisciplinary applications
in science and engineering.  A combination of simulation models and numerical
methods may be required to solve the overall problem in which each subdomain 
component may need a different set of problem-solving techniques with little or no commonality. 
The interface among individual disciplinary applications can
be quite complicated and sometimes nonlinear. A good example of  
a meta-problem can be found in the Multidisciplinary Analysis and Design (MADIC)
project developed at NPAC \cite{madic}.
In this project the analysis and design of large-scale, complex products such as
aircraft and automobiles require a combination of multiple engineering and scientific
disciplines that include fluid dynamics, structural dynamics, heat transfer, 
combustion, and manufacturing. Another example is the NASA Grand Challenge data
assimilation application, jointly developed by NASA Goddard, NPAC, and JPL
\cite{assimilation} to simulate important phenomena associated with environmental global changes
such as greenhouse-gas, ozone loss, and atmospheric pollution.  In this application,
in each step of a step-wise analysis 
a Semi-Lagrangian transport model is tightly coupled with
an Optimal Interpolation model. The transport model is physically motivated
in an icosahedral 3D sphere geometry whose algorithm has significant irregular
and dynamic computational requirements.  An optimum
interpolation analysis technique is used to interpolate data from random spatial 
locations of approximately 100,000 observations to a regular grid. Yet another example 
in much smaller scale but representative, to be elaborated on in Chapter 3, is a 
Moment-Method-based radar cross-sectional (RCS) problem in computational electromagnetics \cite{src}.
The problem structure of this application can briefly be described as follows: A finite
element method using triangular patches is used to discretize the three-dimensional 
geometry surface of a RCS target in arbitrary shape, and a stencil integral
is calculated to give the EM characteristics at each point.  The result is
represented in a 2D matrix, and a matrix solver in linear algebra is used to
solve the linear equations representing the results of the finite element approach in
the former part. In this case, two different methods --- finite element and linear
algebra --- are emloyed to formalize the problem structure, and a matrix is used to link the
two components linearly. 

In terms of the way in which problem components interact with each other, meta-problems are
usually an asynchronous collection of loosely synchronous components where
each component program module may be parallelized in a fine granularity of
data and task decompositions.

\item
{\bf Computational time and space requirements}

The computational complexity of meta-problems is usually enormous.  They
tend to require more physical space, finer resolution, more accuracy, and faster response time to be able to realistically model/simulate real world problems
or uncover new phenomena in science, tasks that were previously
impossible or unrealistic on a single conventional computer or supercomputer.  
For example, in Chapter 4 we note in our description of a financial modeling application that, despite the fact that they are far more accurate than any
model popularly used by the commercial market,
option-pricing models based on either the Monte Carlo or the binomial
method
are used in academia for theoretical purposes due to the enormous
CPU requirements of the algorithm.
Only since the breakthrough in computational power in high-performance
systems has it become possible 
to bring them into practical applications in industry. Many Grand Challenge applications
prove that realistic modeling will be possible only with orders of magnitude 
increase in computational performance \cite{hpcc2}.

\item 
{\bf Rich data source and data types}

A meta-problem may be computationally intensive simply because
the volume of data to be processed is enormous. 
For instance, for many National Challenge applications
information processing, rather than simulation, is the the major demand.
One example is the so-called ``data mining'' application where
strategic decisions are based on the processing and analysis
of a large amount of historical data that require high-performance
systems with powerful processors, advanced database management, and 
intelligent analytic methods.

It is expected that by the end of the decade
high-speed networks will 
enable the integration and coalescing of vast
amounts of information stored in diverse databases. This will provide 
unprecedented new opportunities to acquire
new knowledge by applying various data-gathering and data-mining processes 
to such massive databases. Data types include not only text and binary
but all sorts of multimedia data such as images, audio, and video.
These goals will likely be
met, but not without significant advances in our understanding of how to build and
integrate high-performance parallel database management systems, 
parallel and distributed I/O, artificial intelligence,
and multimedia applications such as Web-based applications
that are efficiently executed on a variety of parallel 
and distributed hardware architectures. 

In Chapter 5 we will describe such an application in Web/RDBMS integration,
building a Web search/archive system for structured USENET newsgroups, and
an unstructured full-text Web document on a parallel database management system.

\item 
{\bf Problem abstraction and task decomposition requirements}

The creation of higher-level problems and machine abstraction is a
fundamental concept in 
computer science and engineering. An abstraction is a simplified interface
that provides access to some underlying lower-level mechanism. It is also a
representation of problem entities or components that are relatively independent and
logically isolated. There is usually a hierarchy of task and data abstraction
associated with each level of problem abstraction in a top-down fashion. 

Abstractions are useful for managing complexity and for analyzing system
architecture. Higher-level abstraction that is closer to problem structure gives a better
structural overview and understanding of a complex problem. Lower-level
abstraction that is closer to the machine and implementation structure
gives better details on exact implementation efficiency and machine dependency. 
A hierarchy of task and data abstraction is essential to system analysis, software
development, and system integration. The refining process of such abstractions
is  
actually the realization of the design-mapping process from an application description to
its computer implementation. Parallelism may exist at every level of the
abstraction problem. A good mapping scheme/methodology should preserve 
inherent parallelism in the problem domain while utilizing efficient
implementation on parallel systems.
Different computer implementation stages may require different levels of
task and data abstraction.

\item
{\bf Multiple functionality and resource requirements}

Parallel computation is not the only task in a meta-problem.
A complete real-world application may need to support
diverse functions that require multiple computing resources such as
processor power, I/O, 
networking/communication media, programming models, 
database management, graphics and data visualization, 
real-time simulation and modeling, etc.
The demand may come from
\begin{enumerate}
\item 
a variety of computing services/resources to be employed;
\item
interoperativity and interfaces among components; or
\item
functional parallelism.
\end{enumerate}

A parallel software support environment should be able to
combine different computing services in an effective and coherent way. 

\end{enumerate}

The hardware computing environment provided by vendors usually consists of heterogeneous computing 
platforms with associated data storage devices linked by communication
channels. The computing environment needed by application developers supports
rapid porting or prototyping of software codes that can make efficient use of 
vendor-supplied hardware. The software infrastructure that normally provides the
interface between application developers and computer software
seriously lags behind hardware advances. Difficulties also exist in providing system
software for heterogeneous platforms, since system software has
historically been 
developed by vendors who optimize the software for their own platform.
This has become further exacerbated by bottlenecks in the development of application
software because of associated paradigm shifts persistently occurring, which
include:

\begin{enumerate}
\item Development of a range of parallel computers with different
architectures and power.

\item Integration of either homogeneous or heterogeneous computing platforms into
meta-computers. The meta-computer is a uniform interface to disparate computing
platforms, providing the application programmer the opportunity to decompose the
application problem across multiple machines.

\end{enumerate}

On the other hand, different problems will generally run most efficiently on different
computer architectures. It is generally agreed that there is no single parallel
system architecture that can handle universal applications of any type most
efficiently. A range of different architectures will be available for some time
to come, including vector supercomputers, SIMD massively parallel systems, MIMD
distributed-memory machines, shared-memory SMPs, and networks of workstations.

The user would prefer not to have to deal with details of the
different hardware, software, languages, and programming models for
the various classes of machines. Therefore, the aim of system and 
software integration is
transparent distributed computing, sometimes called ``meta-computing,''
to provide simple, transparent access to a group of machines
of different architectures connected by a high-speed network to each other
and the outside world, and to data storage and visualization facilities.
Users should be presented with a single-system image so they do not need
to deal with different software, languages, software tools, and
libraries on every machine. They should also be able to
run an application across different machines on the network.

Meta-computing implies not only different computer architectures but
different languages, new software, and new libraries. It will open up
computation to new fields and new applications, and offers a different
way of viewing problems. Virtually all complex real-world meta problems are
inherently parallel in that many different elements of the problem
domain interact with one another at any given time. In a sequential
language the structure of the problem must be artificially broken up to
fit within the confines of the sequential computer, for which only
one computation can occur at a time. Using parallel computers and parallel
languages allows the programmer to better preserve the problem
structure in the application, and also in the algorithm.

To solve complex and computationally (or informationally) intensive problems 
such as meta-problems, we need to employ a whole computing infrastructure and
a software environment to bear on those application requirements at very 
high performance. 
We therefore define ``meta-computer'' as a framework of a system
infrastructure and a software engineering environment that is composed of 
a heterogeneous collection of disparate computer systems and data storage systems
integrated by high-bandwidth LANs, all at one site. Associated with the meta-computer
infrastructure is a parallel software engineering framework consisting of
a set of resource management and programming support software necessary to
effectively apply computing facilities to meta problems. The software
integration framework to be discussed in this thesis is one of such efforts to
build a meta-problem solving environment on meta-computers.

A meta-computer can be as small as a single parallel system or as
big as all of the facilities in a supercomputer center. As an analogy to a uniprocessor
system, a meta-computer has the following major computing components:

\begin{enumerate}
\item
CPUs (distributed and heterogeneous in size and power vs. single CPU)
\item
RAMs (distributed memory components vs. integrated chips in VLSI)
\item
Interconnections (inter-networking vs. BUS)
\item
I/O channels and peripheral data storage devices (loosely distributed versus
tightly centralized)
\end{enumerate}

Meta-computers share the following common features:

\begin{enumerate}
\item
{\bf Heterogeneity}.
The computing elements in a meta-computer may be from different vendors with different
architectures and varied capacity for speed, power, bandwidth, configuration, etc.
The motivation for migrating to heterogeneous environments is the potential to apply
the most suitable computing systems to the different parts of a given program, thus better 
matching resources to computing needs. 

The majority of computationally intensive applications perform well on 
parallel computers by taking advantage of the simple idea of ``data
parallelism,'' which means obtaining concurrency by applying a particular
algorithm to different sections of the data set concurrently. Data-parallel
applications are scalable to a larger number of processors for a larger amount
of data.

Another type of parallelism is ``functional parallelism,'' where different
processors (or even different computers) perform different functions or
different parts of the algorithm. Here, the speedups
obtained are usually more modest and this method is often not scalable;
however, it is important, particularly in multidisciplinary applications.

Surveys of problems in computational science have shown that the vast
majority (90\%) of applications can be run effectively on MIMD machines,
and about 50\% can be run efficiently on SIMD machines. Currently, there are many different parallel
architectures, but only one --- a distributed memory MIMD multicomputer ---
is a general, high-performance architecture known to scale from one
to many processors \cite{hpcc1}.

Not only are the computing elements in a meta-computer heterogeneous, the programming
environment on which it is supported is expected to be quite different from
other environments.
The broad range of HPCC applications may embody a rich 
diversity of program structures, and it is anticipated that no one parallel programming model
will satisfy all needs. Data-parallel, task-parallel, and object-parallel forms have all found
applicability to end user problems and are expected to continue to do so. 
A parallel programming environment will incorporate them into a single schema 
 that provides
means for a single application to use different languages or different parallelism models 
for separate parts of a problem. 
Porting and rewriting applications programs also require a heterogeneous
support environment that 
encourages code reuse, portability among different
platforms, and scalability across similar systems of different size. Necessary
to achieve this is an integration framework that seamlessly couples 
key programming elements that include parallel
I/O and message-passing primitives as well as parallel programming support tools.
This framework will
of necessity support interoperability among independently derived program
modules running on separate computers in a distributed
heterogeneous computing environment. 

\item
{\bf Distributed elements}. In a meta-computer almost all elements are distributed. Nothing
is shared except the interconnections binding them together
into a single system image. The shared-nothing or
decentralized feature makes a meta-computer different 
from a distributed-memory MIMD machine, on which most base-operating 
system software is still tightly integrated and centralized with 
the distributed architecture.
A software integration system on a meta-machine
is very similar to the OS software on an MIMD machine, except that it must deal
with all the shared-nothing components and create a shared software environment
for applications.
Still, the degree and level of
distribution is in a hierarchy so that all software technologies developed
on a particular system can be reused and integrated into this much broader
meta-level environment.
\item
{\bf Coarse-grained}. The characteristics of distributed and heterogeneous
software and hardware components in a meta-computer determine that
they are in coarse grain. Task parallelism and functional parallelism
are the only sources of parallelization that can be exploited at the highest
level of an integration framework.

\end{enumerate}

An example of a meta-computer can be found in Appendix A where the NPAC in-house
computing facility is described. Most of our case studies in the later chapters are built
on this meta-computer.

\section {Software Integration for Meta-Problems and Meta-Computers}
Solving a complex problem on a complex system
requires a sophisticated software engineering environment.
The computing environment areas include data storage, communications, and programming 
support environments. Applications are inherently limited by the capabilities of
the computing environment and access it 
provides. 

Standardization of the programming environment is complicated by the
competing factors of  granularity versus locality for both task and data. Task or data granularity is
a decomposition metric with the issue of whether one should restrict fine-grained 
decompositions to local environments (i.e., within one machine) or
to loosely coupled machines.
Task or data locality is a task/data distribution metric that addresses the issue of whether a 
particular application will work well on distributed memory architectures.
Since application algorithms may require a particular task/data locality or
granularity pattern for efficient execution, there may be
multiple programming environments that will need to be supported.

Programming environments for meta-computers must go
beyond conventional parallel languages and message-passing programming
in expressivity and program execution. In addition to the normal
requirements, programming environments must incorporate semantic constructs
for delineating program parallelism, identifying locality and specifying
data set partitioning, coordinating disparate components, and so on.

The approach
we propose, to be elaborated on in later chapters, is a dataflow-based
software integration framework that stems
from other examples arising in 
graphics dataflow systems such as AVS/Khoros.
We believe that successful software integration models should be
built around meta-problems and not around meta-computer architectures. 
Parallel languages and tools should be able to map problem components
containing various diverse structures into a range of computer architectures,
transparent to the software integration framework and to programmers.

We define
software integration as the sum total of the assimilation
effort to plan, procure, and construct a fully operational computing
environment by combining pre-existing and new
program components for a complex application into a single unified
programming framework in a seamless way so that the application
is accomplished effectively.
We can view parallel software integration as a framework with which
components of a meta-problem are mapped onto computing elements of
an meta-computer in a single integrated environment so that various
distributed computing resources are optimized to solve the application
problem.

Software development on HPDC systems has in the past been focused
on developing efficient parallel algorithms and
specialized software components to run fast on a parallel system.
A stand-alone program comprising a
command-line interface and a few specialized functions was usually
sufficient for
a successful parallel software application.
However, real-world applications such as meta-problems 
demand more than just parallel algorithms.
It is expected that parallel software systems will have graphical user
interfaces; software systems will incorporate complex data types such
as imagery, graphics, and other multimedia; and a parallel software will
require integrated database capabilities to manage and process 
a large data volume.
Heterogeneous computing environments are a reality in most organizations
where differences between platforms reinforce the need for
multi-vendor integration solutions. 
Most systems solutions today require a great many components, often from a 
variety of product vendors operating in
harmony with one another. The process of software integration is the 
optimization of disparate software and
components toward the construction of a seamless operation to ensure that the components 
of the computing environment are well-matched, complementary, and tuned for optimal performance. 

Research scenarios in system and software integration include the following:

\begin {enumerate}
\item
Distributing portions of a given job between platforms so that each
portion runs on the most amenable platform: for example, 
using a CRAY C90 and a Paragon to solve a 
quantum chemistry reaction dynamics calculation over a
Gigabit testbed. 

\item
Solving a problem on one platform and transferring the data to a second
platform for processing, visualization, and archiving; for example,
to conduct an ocean modeling with the problem solved on the CRAY T3D
and the output data visualized on a different machine.

\item
Obtaining remote-sensing data from an archive on one platform, then
processing the data on a second platform.
\end {enumerate}

The scale of these meta-problems requires integrating a variety of needed
resources into a single, easy-to-use capability that spans parallel
and distributed computation, data
access, data manipulation, and data visualization. This
integration can result in decreased computation time, decreased
data-processing time, decreased time to interact with the data to massage it
into a usable form, and decreased time to interpret the results. In short,
this integration allows the researcher to solve the problem much more
quickly, resulting in a more rapid prototyping process.

Such capabilities can be constructed by linking resources at the application
level through a heterogeneous computing environment software layer or at the
operating system level by explicit modifications to each of the linked
platforms. The former is expected to provide
an easier migration path for new hardware and software systems. The latter
is expected to provide higher performance. Either approach requires the
development of a significant amount of software infrastructure, and both
require the solution of similar underlying problems. 
We adopted the former approach in our work.
In Chapter 2, Section 4, we give a brief review of similar work in software
integration approaches adopted by other research groups.

\section{Software Integration in a Problem-Solving Environment}

One can view software integration from the perspective of building
a problem-solving environment on HPDC systems.

Research in problem-solving environments (PSE) has been active since the
1960's, 
soon after high-level programming languages were invented \cite{pse}.
In general, a PSE is a computer system that provides all the computational
facilities necessary to solve a target class of problems.
Major features in a PSE include advanced solution methods, automatic
or semiautomatic selection of solution methods, ways to
easily incorporate novel solution methods, transparent use of underlying computer 
software and hardware, and a framework to solve simple or complex
problems and for rapid prototyping or detail analysis.

While most of the research and practice of PSEs in the 1970's and 1980's
was hindered by the lack of computing power, advances in high-performance
computing, combined with a better understanding of computing and computational
science in the 1990's, have put PSEs well within our reach. The recent refocus of the
US HPCC program on national challenges has generated new
incentives in this area in which PSEs can help build large-scale
application systems in areas where problems and their solution methods
are well understood and efficient (parallel) computer algorithms have been
found and widely practiced.

\begin{figure}
\centerline{\epsfxsize=450pt \epsfbox[60 160 550 720]{chapter1-introduction/pdelab.eps}}
%BoundingBox: 50 530 550 720
\caption{Layered software architecture for a PSE for PDE applications}
\label{pse}
\end{figure}

One of the most important issues in a PSE is the software architecture used
to assemble, organize, and orchestrate system components to allow gradual
growth and evolution during its life-cycle. Building a PSE on a distributed 
parallel computing system such as the meta-computer tends to be more
difficult and challenging than on a uniprocessor computer, as
it now has to deal with the system complexity at both ends.

A software integration in a PSE will need to support the following
key capabilities:
\begin{enumerate}
\item
Rapid prototyping for architecture specialization and 
customization: a PSE should allow a user to rapidly
integrate and connect modules consisting of computation kernels,
libraries, and user interfaces.
\item
Portable interfaces to avoid monolithic code: PSE modules should be
able to execute on networked machines. A constructed PSE
can consist of modules running on a variety of modules
simultaneously by using the computing
and visualization resources most suitable to each.
A PSE can also contain multiple copies of modules running in parallel, as well
as modules that contain parallel code.
\item
Efficient module resolution to allow a user to create customized
modules, to connect modules running on remote machines, and
to select modules for different purposes.
\item
Capture the complexity of systems while
hiding complexity and heterogenity: an integration frame is a layered
collection of program objects that work together
to hide increasing levels of complexity within target problem
domains.
\end{enumerate}

A software component architecture plays a critical role 
in building a PSE.
For example, Figure \ref{pse} gives a three-layer software architecture
for the development of PSEs for PDE-based applications \cite{pdelab}.
At the top layer, a set of tools is provided to specify the input and
to interact and observe various facets of the ``hybrid'' numerical
and experimental models used to simulate various applications.
These tools allow users to solve problems by communicating in the user's
terms. The bottom layer involves the various meta-libraries for the
numerical simulation of various physical objects and knowledge bases that
support the computational intelligence of domain-specific workbenches. 
These libraries are portable on specialized, generic, and virtual machines.
Between the two layers sits a middle-ware whose objective is to glue a range of 
independent subsystems and tools. A software integration framework
is required to lay down the backbone for this software architecture, and it
is this middle-ware that plays the integration role in a PSE environment.

The building blocks of a PSE are of various component technology,
general or specific for application domains. Examples of generic
components technology include:

\begin{enumerate}
\item
User interfaces, such as World Wide Web, X-window, Motif
\item
Database or knowledge-based systems such as Oracle, Illustra, expert systems
\item
Programming languages and compilers such as Fortran90, PVM, MPI
\item
Numerical libraries such as LINPACK, ScaLAPACK, CMSSLL
\item 
Collaborative tools such as IRC chat, whiteboard
\end{enumerate}

Different PSEs may need to combine different component
technologies. However, a universal PSE architecture
must allow ``plug-and-play'' of new algorithms or data structures
so that it does not exclude key technologies. In addition,
a PSE framework should support a distributed software development
approach with synergistic contributions from loosely
coupled groups of researchers. Research in software integration
will rely on advances in the following computer science areas:
\begin{enumerate}
\item
Object-oriented technology such as CORBA, JAVA, C++
\item
Visual programming and GUI such as Visual Basic, Delphia, AVS
\item
Software engineering methodology
\item
Networking and distributed computing
\end{enumerate}

Support for interoperability is
critical in PSE. By interoperability we mean the ability of two or
more programs to communicate or work together despite having been written
in different programming languages or models. The need for 
interoperability arises in many contexts of a PSE. Generally,
the desire to combine programs written in different languages springs from the
availability of specific capability in some particular language,
programming model, processor, or existing program. For example, the 
number-crunching power of a vector processor and the availability
of a particular numerical analysis package in Fortran90 might 
entice a programmer to attempt interoperation of a PVM program 
running on a cluster of workstations and a CMFortran (CMSSL) code
running on a CM5 with vector-processing capability. One of the common goals in
a PSE and software integration is to seamlessly facilitate software 
and application interoperability.











