\documentclass{book}
\usepackage{psfig}
\begin{document}
\chapter{NetSolve: Network-enabled Solvers}
\section{Motivation and History}
The current software usage model entails three basic phases:
i) obtaining the software (locating and/or purchasing, investigating
licensing, import and export restrictions, etc.) ii)installing the
software, and finally, iii)using the software. In addition to these
mundane tasks, maintenance of the software system is also necessary
to ensure that the latest versions are being used and to attain
patches and bug fixes. The NetSolve project, underway at the University
of Tennessee at Knoxville and the Oak Ridge National Laboratory had very
humble beginnings. Its original goal was to alleviate domain scientists
of this tedium when trying to use numerical software, particularly on
multiple platforms. And so it began, a sole interface, Matlab, with access
to solver routines from the LAPACK library. The first major release of
NetSolve was in 1995.

Today, NetSolve has evolved into one of the leading research projects in
the area of Grid computing. Its various interfaces provide uniform access
to an assortment of software toolkits and libraries. These libraries come
from a diverse sphere of influence, ranging from mathematical solvers to
more eclectic domains like microbiology and image visualization. Currently
at version 1.2 released in the fall of 1998, the NetSolve system receives
continual enhancements and feature upgrades. A beta version of 1.3 will be
available in the fall of 1999 with a non-beta distribution slated for release
in the early spring of 2000. The NetSolve software is freely available and
can be downloaded, along with additional documentation and related papers,
at:\\
	\centerline{\tt{http://www.cs.utk.edu/netsolve}}

\section{The NetSolve Philosophy}
As research scientists continue efforts to harness as much computational
resources and power as possible, NetSolve continues to position itself in
the midst of it all. As the system becomes more enhanced and, unfortunately,
more complicated, there are certain fundamentals that we try to maintain in
our NetSolve system. The first and foremost is that the system is very easy
to deploy and use. The thing that should be furthest from the thoughts of the
middleware user is how to incorporate software that in and of itself, he is
not interested in. What he really wants is the software and hardware resources
that the middleware makes available to him. Although simplicity is of the
essence, the interface must still be intricate enough to meet the full needs
of its users. NetSolve exerts much effort to do the impossible; be simplistic
yet complicated at the same time. We have managed to achieve what we believe
to be an adequate, if not perfect, balance between the two.

Another perspective of NetSolve concerns the integration and usage of other
Grid computing infrastructure. As opposed to re-inventing the wheel, we try
to leverage on the accomplishments of the Grid computing community at large.
But all our designs ensure that we are dependent on none of these systems.
Should their resources be available in any of our users' domains, we gladly
take advantage of them, but the NetSolve system can and most often does
stand alone without infrastructure native to the NetSolve system.

\section{The Infrastructure}

\begin{figure}[Hht]
\centerline{\psfig{figure=netsolve.ps,height=3.7in,width=4.6in}}
\caption{The NetSolve System}
\label{ns_overview}
\end{figure}

\subsection{The Big Picture}
As depicted by Fig. \ref{ns_overview}, NetSolve is of a client/agent/server
design in which the client issues requests to agents who allocate servers to
service those requests; the server(s) then receives inputs for the problem,
does the computation and returns the output parameters to the client. The
NetSolve client-user gains access to limitless software resources without
the tedium of installation and maintenance. Furthermore, NetSolve facilitates
remote access to computer hardware, possibly high-performance supercomputers
with complete opacity. That is to say that the user does not have to possess
knowledge of computer networking and the like to use NetSolve. In fact, he/she
does not even have to know remote resources are involved. The NetSolve system
is further enhanced by features like fault-tolerance and load balancing. In the
sections below, we offer a brief discussion of the three aforementioned components.

\subsection{The Client Interfaces}
A major concern in designing NetSolve was to provide several interfaces for
a wide range of users and flexibility. NetSolve can be invoked via C, Fortran,
MATLAB and Mathematica interfaces (the Mathematica interface is available only
on Win32 client platforms). In the past, we supported a Java Application
Programming Interface (API) and  web-based Graphical User Interface (GUI) and
are undergoing efforts to upgrade these interfaces to the current version of
NetSolve. Another concern was to implement interfaces that were as simple as
possible yet while being meticulous enough to allow the user to control
execution of the remote procedure as much as possible. For all the interfaces
involved, we two basic functions. The first allows for synchronous or blocking
requests that do not return until remote execution is complete (or failure is
detected). The second is a more non-traditional asynchronous or non-blocking
request that returns immediately giving the user a "handle" which he can use to
query the readiness of and/or obtain the solution set. In addition to these, we
provide in the API functions to do error reporting. We also provide the
capabilities to dynamically query a NetSolve system to receive information about
either the hardware or software resources. These are used primarily  to determine
which problems are available and the number, type and description of the input
and output parameters each problem requires. In the case of command line
interpreters like Matlab and Mathematica, these are in the forms of functions.
For the compiled interfaces, C and Fortran, these are compiled executables.

\subsection{The NetSolve Agent}
\subsubsection{The Agent as a Database}
Keeping track of what software resources are available and on which servers they
are located is perhaps the most fundamental task of the NetSolve agent. The agent
keeps a database that maps software resources to hardware components in the
NetSolve system thus having an complete picture of the capabilities of both the
individual servers and the NetSolve system on a whole. The agent can report this
information to the client via the interfaces (see above) which will then aid the
user in setting up his problem on top of the NetSolve middleware. The protocol
which NetSolve uses to maintain this database is fairly straightforward: Upon
initialization, a new server sends a "problem description" for each problem it can
solve to the agent it was configured to register with. This description, among
other things, contains the location of the server and the particulars of the
function(s) being contributed. Eventually the server is integrated into the system
and can be used to service users' requests.

\subsubsection{The Agent as a Resource Broker}
In order to expeditiously service user requests, it is necessary that the agent use
certain criteria to choose the best-suited computational server for each incoming
request. There are two basic choices: i)static scheduling where at compile time the
agent is programmed to use some apriori scheme like round-robin scheduling and ii
dynamic scheduling where the agent uses run-time information to decide which server
component should be used to service a request. NetSolve uses the latter. In
actuality, it combines both static and dynamic information. Static information
includes speed and number of processors and complexity of the solution algorithm.
Dynamic information includes server loads, network delays and transmission rates,
and input data sizes. The agent then uses this information to rank the servers from
best to worse. This list is passed to the client and the client makes its request to
each server in turn until either the problem has been successfully solved or the list
has been exhausted.

\subsubsection{Fault Tolerance and Load Balancing}
The protocol described in the resource brokerage section above has its primary goal
rooted more in high throughput than balancing load amongst the servers. In a scenario
where there is a high performance supercomputer acting as a NetSolve server along with
other stand alone mediocre workstations, with several simultaneous requests most of them
will be sent to the supercomputer (as long as the supercomputer is determined to be the
component that will finish the service quickest). In a scenario where all server resources
are of essentially the same rating, however, this same paradigm will balance the load
evenly amongst the servers since this scenario will then yield highest throughput.

For fault tolerance, NetSolve ensures that a user request will be completed unless every
single resource capable of servicing the request has failed. As explained above, when a
client sends a request to a NetSolve agent, it receives a sorted list of computational
servers to try. When one of these servers has been successfully contacted, the computation
starts. If the contacted server fails during the computation, then another server is
contacted and the computation restarts. This entire procedure is transacted independently
of, and possibly unbeknownst to, the client user. Though effective, this primitive
fault-tolerant mechanism needs to be enhanced. In the next section where we discuss current
developments, we describe our research to employ more advanced fault-tolerance.

\subsection{The Computational Server}
One of the challenges when building the NetSolve system was to design a
suitable model for the computational servers. For the user to be able to
invoke numerical software directly through our servers, three major features
seemed to emerge as mandatory for the servers:
\\
\\
\underline{Uniform access to the software}: The NetSolve servers should present the
interfaces with an illusion of uniformity amongst the various integrated packages. The
critical point is to try as much as possible to maintain high levels of consistency
amongst and within the different sets of subroutines/functions provided to the user.
This allows the user to focus on the particular problem he is trying to solve rather
than the peculiarities of the software package he is using to aid his investigations.
This also eliminates long learning phases when using new functionalities.
\\
\underline{Configurability}: The server should not be confined to any particular
software. It was, therefore, essential that we provide a framework that permitted
the addition of functionality to a computational server. This framework should be as
intuitive as possible and general so that one can integrate any software toolkit with
NetSolve servers and make them accessible to the client interfaces.
\\
\underline{Pre-installation}: As stated in the last section, we wished to ease the user
of the burden of software installation. Therefore, in the NetSolve paradigm, the client
user is not responsible for installing any software directly. The software is made
available via the NetSolve servers in a read-to-use fashion. It is also possible in some
scenarios for the NetSolve system to dynamically install and compile routines without any
intervention at the user-level.
\\
\\
The NetSolve server addresses and successfully resolves all these issues. Mainly through
the use of what we call a {\tt problem description file} (PDF), the server can be
configured with a set of pre-installed software libraries to provide uniform access to
the sub-routines provided. The PDF in essence describes the particulars of a function to
be added. Some of the information that is described in this file are the name to be given
to the problem, the calling sequence to the NetSolve client interface, the libraries or
archives containing the underlying functions being integrated and other things. The PDF
really describes a wrapper that is used to receive or send input and output parameters from
and later back to the client interface. In the midst of these networking transactions is a
call to the routine from the underlying library to actually do the service that was requested.
Although network interactions are involved, neither the client nor the writer of the PDF needs
be concerned with this. The NetSolve system carefully encapsulates and hides these
interactions from the user. These wrappers are parsed and compiled into source codes which are
compiled with the library archives into NetSolve specific executables. The appropriate
executable is initiated by the server daemon whenever it needs to service a client request.

\section{NetSolve in Context}
In this section, we give a brief description of the role that NetSolve has been playing in the
world of Grid Computing. We describe some of the applications that have taken advantage of
what NetSolve has to offer. We also discuss some of the other metacomputing resources that
NetSolve has used to leverage itself.

\subsection{NetSolve and Other Metacomputing Resources}
\subsubsection{Globus}
Globus is a software system that provides infrastructure for computations that
leverage distributed computational and informational resources. It is being
developed at the Argonne National Laboratory and the University of Southern
California's Information Sciences Institute. Currently, the NetSolve system uses
a component of Globus referred to as the Heart Beat Monitor (HBM.) The HBM allows
NetSolve to easily detect failed server hosts and update the agent's database. We
are also testing a new NetSolve proxy-client that allows Globus-enabled NetSolve
client users to access and use Globus computational resources through the NetSolve
interface.
\subsubsection{CONDOR}
The CONDOR system, of the University of Wisconsin, takes advantage of the fact that
many CPU cycles go wasted on idle workstations at times when the primary user is not
using his or her machine. The system assigns tasks submitted to the CONDOR system
to "registered" host machines as long as these machines are idle. Should an owner
return to his machine, the task is immediately halted and assigned to another host.
CONDOR pools can be used as NetSolve servers. In essence, the request for service is
forwarded to the CONDOR system which then assigns the task to an idle workstation for
completion.

\subsubsection{Ninf}
Ninf is a system very similar to NetSolve. Developed at the Electrotechnical Laboratory in
Tsukuba, Japan, it too provides an interface that allows for remote execution of functional
components. In a collaborative effort, a NetSolve-Ninf bridge has been built that allow
both systems to utilize servers provided to the other. Administrators of NetSolve and Ninf
systems can then join forces to create an even bigger computational Grid.

\subsubsection{Legion}
Legion is an object-based metasystems software project at the at the University of Virginia.
Its object is to tie together hosts systems with high-speed links and present the illusion
of a single computer with access  o varied physical resources. The NetSolve client-user can
use the NetSolve interface while leveraging metacomputing resources of Legion. The NetSolve
client side uses Legion data-flow graphs to keep track of data dependencies.


\subsection{Some Applications of NetSolve}
\subsubsection{MCell}
MCell is a general Monte Carlo simulator of cellular micro physiology. MCell uses
Monte Carlo diffusion and chemical reaction algorithms in 3D to simulate
the complex biochemical interactions of molecules inside and outside of living
cells.  MCell is a collaborative effort between the Terry Sejnowski lab at the 
Salk Institute, and the Miriam Salpeter lab at Cornell University.
\\
\\ 
NetSolve is very well suited to MCell's need and this project aims at writing
a NetSolve-based framework to support large MCell runs. One of the central pieces
of that framework is a scheduler that takes advantage of MCell input data
requirements to minimize turn-around time. This scheduler is part of the larger
AppLeS at the University of California, San Diego. The use of NetSolve isolates
the scheduler from the resource-management details and allows researchers to focus
only on the design of the scheduler.

\subsubsection{IPARS}
IPARS is a framework for developing parallel models of subsurface flow
and transport through porous media.  It currently can simulate single
phase (water only), two phase (water and oil) or three phase (water,
oil and gas) flow through a multi-block 3D porous medium. IPARS can be
applied to model water table decline due to overproduction near urban
areas, or enhanced oil and gas recovery in industrial applications.
\\
\\
IPARS is being made into a fully functional NetSolve server. The goal of
this project is to allow this server to be accessible via a web browser
using the Common Gateway Interface on top of NetSolve's C interface.
The server will also render animated graphics via a destination web-page.
This total web-accessibility will allow those wanting to see IPARS simulations
to do so with nothing but simple input parameters defining the simulation.

\subsubsection{SCIRun}
SCIRun is a scientific programming environment that allows the interactive
construction, debugging and steering of large-scale scientific computations.
SCIRun can be used for interactively: i)Changing 2D and 3D geometry models
(meshes), ii) Controlling and changing numerical simulation methods and
parameters and iii)Performing scalar and vector field visualization.
\\
\\
Currently, NetSolve is being integrated into SCIRun as the broker for
computational resources. This integration will allow for increased 
parallelism and performance in the SCIRun paradigm.
\subsubsection{LUCAS}
LUCAS is a system that uses computer modeling to integrate
biological and socioeconomic data of land areas to help natural resource
specialist evaluate the consequences of alternative land management scenarios.
It uses the Geographic Information System, GRASS, to represent and manipulate
spatial data on workstations.
\\
\\
There is an on-going effort to integrate NetSolve to harness the computational
cycles for LUCAS. This will prove especially useful when LUCAS is used
to spawn several "replicates" which normally would compute
in serial on the local machine. Using NetSolve, the computations would
be done in parallel, possibly on machines specialized for High Performance
Computing.
\subsubsection{DIPS}
DIPS is a software tool, developed at the Computer Graphics and Vision unit of the
Graz University of Technology in Austria, which allows remote computing for image
processing. DIPS extends the Image/J Java image processing application to provide
remote access to the high-performance ImageVision library by Silicon Graphics.
\\
\\
At its core, DIPS uses NetSolve as its metacomputing resource to provide 
unprecedented computing power by aggregating distributed resources on the Internet 
to a single system.
\section{Current Developments and Future Research}
\subsection{Dynamic Server-software Enhancements}
In the current NetSolve design and implementation, there is a tight coupling
between the server's hardware and software components. The server is statically
configured (at compile time) to solve a particular problem set. Although we
have provided the tools to allow this problem set to be easily expanded, this
can only be done initial configuration, so to increase a running servers capability
entails a shutdown, reconfigure and restart loop. This will not be the case in
the next major release of NetSolve. We are providing the capability of storing
NetSolve specific software binaries (See Sect. \ref{}) in a software
repository whose location is known to the NetSolve agent. At request time, should a
particular server not possess the appropriate binaries, it will be directed to
the repository for a download. This paradigm will not replace, but will enhance,
the current protocol where the server is statically binded with software.

\subsection{Fault Tolerance}
As explained in Sect. \ref{} the fault tolerance possessed by the NetSolve system
incorporates only a retry and restart mechanism. We are presently developing servers
enhanced with checkpointing capabilities. As they run, the servers will take frequent
checkpoints (via a core dump mechanism); should one of these servers fail, they will
be restarted not from the beginning, but from the state represented by the core image
of the most recent checkpoint. Homogeneous migration will also be possible, meaning
that it will be possible to restart the process on a different machine of similar
architecture and operating system. As this feature becomes more advanced, we will
investigate heterogeneous migration and possibly checkpointing parallel programs.

\subsection{Request Sequencing}
We recently investigated a bit of research that would allow us to minimize the
network traffic between client and servers in a single client program that made
numerous requests to NetSolve. We noticed that, in many cases, there exists data
dependencies between these requests. We have implemented a feature that allows the
client user to bracket together multiple requests to NetSolve. The NetSolve system
then analyzes data dependencies and only sends to the servers the minimal data
necessary. Inputs to later requests that were outputs of a previous request(s) need
not be obtained from the client again. The server makes this data persistent and uses
it across all requests as necessary. In our current model, all request must execute
on a single server. Future research will yield a model that will investigate using
systems like the Internet Backplane Protocol (IBP) and other distributed storage
facilities to stage data as requests are serviced on multiple servers.

\subsection{Win32 Servers}
The Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. DCOM is based on the Open Software Foundation's DCE-RPC and is a standard similar to that of the
Common Object Request Broker Architecture (CORBA). We will be developing a version of the Netsolve server that acts as a gateway to problem solving libraries and systems optimized for the NT platform. The server will be built using the DCOM protocol to manage its networking
interactions.
\end{document}
