%
%
%  LaTeX source for P. Gray and V. Sunderam's submission to CP&E.
%
%  
\documentclass[10pt]{article}

\usepackage{epsf}              % Assuming dvips for PS generation
\usepackage{vmargin}
\setmargins{25mm}{15mm}{160mm}{215mm}{10mm}{10mm}{20mm}{10mm}

\begin{document}
\title{\null\vskip -1in 
IceT: Distributed Computing and Java
\thanks{Research supported by Army Research Office grant DAAH04-96-1-0083, \
U. S. Department of Energy Grant No. DE-FG05-91ER25105, NASA Grant NAG
2-828\ and the National Science Foundation Award \ ASC-9527186.} }
\author{Paul A.~Gray and Vaidy S.~Sunderam \\
Emory University, Atlanta GA~~USA \\
{\small\tt\{gray,vss\}@mathcs.emory.edu}}
\date{}
\maketitle

\thispagestyle{empty}
\begin{abstract}
\leftskip -1\parindent 
\rightskip -1 \parindent
Metacomputing, or distributed processing on networks (local networks,
intranets, or the Internet), has re-emerged as a technology with
tremendous promise and potential, owing in part to the emergence of
the Java language and programming system. Java both
influences and is influenced by the requisite and dynamic aspects of
network programming. However, its viability as a programming language for
the scientific community is yet to be established. This paper describes
IceT, a novel framework for collaborative and high-performance
distributed computing which has been built upon a Java substrate. The
IceT system exploits the portability and scripting advantages of 
Java and incorporates well established distributed and concurrent computing
techniques into the framework, while retaining the ability to
access specialized processing capabilities and precompiled code.
The result is a dynamic and efficient distributed computing 
environment upon which data and processes are
highly portable amongst heterogeneous platforms and multiple users.
\end{abstract}

\section{The IceT Objective}
There are many contrasts to be found when comparing {\em Internet
programming}\/ and {\em high-performance distributed computing}.
Consider, for example, Internet programming as it relates to 
the World Wide Web.  Users are able to anonymously access processes
and data at remote locations for remote execution
(e.g. a cgi-bin Perl script) or download processes for local execution
(e.g. a Java applet).  In such settings, issues that need to be
addressed include the consequences and implications of executing
processes remotely, anonymously, and securely. On the other hand, in
high-performance distributed computing, where users' programs are
local and executed on local or organization-wide machines,
security is less of an issue and users typically have access privileges
(i.e. anonymity is not a factor).

The aim of the IceT project has been to mutually incorporate
approaches and techniques found in Internet programming with 
established and evolving distributed computing paradigms.
Necessarily, this includes the ideas of harnessing
geographically-remote resources for anonymous utilization, portability
of processes and data, in addition to security issues that naturally
arise. For a good discussion of some other considerations that need to be
made when addressing such a goal, see \cite{chen}.
The integration of Internet and distributed
programming techniques would lead to a natural environment for
collaborative computing and an extension to the traditional
distributed computing environment.  Examples of extended features
incorporated into IceT are: dynamic {\em merging}\/ and {\em
splitting}\/ of virtual machines, multi-user awareness, portability of
processes and data across multiple virtual machines, and a provisional
framework for multi-user programs. This paper describes some of the novel
features of IceT and the role played by the Java programming language.
Details on what is currently implemented and the future of IceT are
given, along with some Java-based examples which serve to
further illustrate the novel features of IceT.


Reiterating, the objective in IceT has been to blend current paradigms
in distributed computing with new and evolving technologies;
including but not limited to the aspects and features found in Java.
IceT builds upon traditional message-passing paradigms found in
distributed computing, such as PVM\cite{PVM}, and mixes with it wide
accessibility and portability of processes as found in both Java and
Internet programming paradigms. A typical active IceT environment
consists of processes executing in unison across multiple networks,
amongst multiple users, and sharing information using IceT's
message-passing substrate.  These processes in IceT are not bound to
any particular filesystem or network because processes are able to
``{\em soft-install\/}'' themselves upon remote systems.  In some
sense, processes are able to be {\em encapsulated}\/ into a
portable package which may be uploaded to any processing component
within the IceT environment for subsequent execution, governed by the
restrictions imposed by the owner of the component.

\section{Java and IceT}
Loosely speaking, the aspects of Internet programming that have been
introduced to distributed computing vis-a-vis IceT relate to uploading
and porting of processes and data; and providing combined, provisional
access to unowned, remote and heterogeneous resources.  The {\tt
ClassLoader} class, {\tt SecurityManager} class, and the JVM are
the major Java components by which these aspects of IceT are realized. 
%
\subsection{The Java ClassLoader}
>From the IceT perspective, the Java {\tt ClassLoader} class is the
primary feature of Java which can be used to complement distributed
computing.  Through the Java {\tt ClassLoader}, processes represented
as Java bytecode can be uploaded, instantiated, and executed on remote
hosts where the ``owner'' of the bytecode has no privileges (e.g. login or
file access) and where execution is subject to security restrictions
imposed by the owner of the local resource.
\par
In IceT, portability of Java bytecode is achieved by extending the
{\tt ClassLoader} class to load, resolve, and instantiate new
instances of classes located on remote hosts.  This component of IceT
is similar to (albeit functionally the reverse of) a web browser which
downloads applets from wide-spread resources across the Internet.  A
user wishing to upload his/her process to a remote IceT host would do
so through an IceT {\tt ClassBootStrapper}.  The {\tt
ClassBootStrapper} extends the Java {\tt ClassLoader}\/ and is
responsible for obtaining and resolving bytecode representations of
class files to be executed.  The {\tt ClassBootStrapper} also offers
configurability; with the ability to impose different levels of
security restrictions to users of the local computational resources
through extensions to the Java {\tt SecurityManager} class.
\par
\subsection{Security}
IceT allows provisional usage of local resources to possibly anonymous
users, so naturally issues relating to security arise.  Java's basic
language-level security protocols provide a sound foundation for the
implementation of security.  The {\tt SecurityManager} class alone
provides a quick and easy means for imposing elementary security
restrictions.  Furthermore, by extending the {\tt SecurityManager},
{\tt SocketImpl}, {\tt Thread} and {\tt File} classes, the local IceT
environment can be configured to accommodate varying levels of
restrictions placed upon workload usage, external and local socket
connections, process portability and file system access.
\par

\subsection{The JVM}
As one of the more common aspects of the Java language, the {\em Java
Virtual Machine}\/ (JVM) provides Java bytecode with a uniform,
system-independent view of the underlying architecture.  With the
guarantee of uniformity of the JVM, bytecode is truly architecturally
independent.  This aspect of the Java programming language allows
platform-independent execution of the Java bytecode regardless of the
platform on which the bytecode was generated.  This allows {\em
any}\/ IceT user to execute {\em any}\/ IceT process.  
\section{IceT Illustrated} 
This section serves to illustrate the suitability of IceT for
traditional distributed computational tasks --- in the form of a
matrix multiplication example --- and to illustrate the novel
attributes and collaborative features brought about by the enhanced
portability of tasks. The examples below assume that an IceT
environment has already been established.  For details on the {\em
adding}\/ and {\em merging}\/ of resources to the IceT environment,
see \cite{IceT1}.


\subsection{IceT and Traditional Distributed Computing}
Consider a distributed program, organized as a master and a collection of slave 
processes to multiply matrices {\bf A} and {\bf B}.  One way
of distributing this problem is to split {\bf A} by rows and to pass
these sub rows of {\bf A} and the entire matrix {\bf B} to the slave
process for subsequent multiplication.  The following shows how one
might program this problem (albeit naively) utilizing IceT and
the Java programming language.
\subparagraph{The Master Program}
The first task is to make the master program IceT-aware, this is done
by {\tt import}-ing the IceT-specific commands.  In order to interact
with IceT components, the program takes the form of an extension to
the {\tt TaskProtocols} class, which defines various IceT functions
such as {\tt IceT\_send, IceT\_recv,} etc. In this example, the master
and four slaves will be responsible for the distributed multiplication
(refer to lines 1-5 below).

\begin{figure}[!ht]
\hbox{
\vbox {\tiny
\begin{verbatim}
     1  import IceT.*;
     2  import java.util.*;
     3  public class MatrixMultiply extends TaskProtocols {
     4    final static int NUM_SLAVES = 4;
     5    final static int NUM_WORKERS = NUM_SLAVES+1;
  ...
    12      try {
  ...
    17        TaskElement myTaskElement = IceT();
    18        /* Prepare to spawn the slaves */
    19        TaskElement[] taskArray = new TaskElement[NUM_SLAVES];
    20        int numSpawned = IceT_spawn("Slave",NUM_SLAVES,taskArray);
  ...
    27        int block = (int) SIZE/NUM_WORKERS;
  ...
    34        /* Pack the entire matrix b */
    35        for (int i = 0; i< SIZE; i++)
    36          bufferB.pack( B[i] );
    37        
    38        for (int k =0; k<NUM_SLAVES; k++){
    39          bufferA.reset();
\end{verbatim}
} \hskip -3.25in\vrule\hskip 0.25in\hfill
\vbox{
\tiny
\begin{verbatim}
    40          bufferA.pack(SIZE);
    41          bufferA.pack(NUM_WORKERS);
  ...
    45          for (int i = 0; i< block; i++) {
    46            int row = k*block;
    47            bufferA.pack( A[row+i] );
    48          }
    49          /* Send off the information to the slave */
    50          IceT_send(bufferA,taskArray[k].myId,888);
    51          IceT_send(bufferB.bufferClone(),taskArray[k].myId,889);
    52        }
  ...
    68        // Reap in the results from the slave
    69        for (int k = 0; k<NUM_SLAVES; k++) {
    70          b = IceT_recv(777);
    71          for (int i = 0; i < block; i++) {
    72            int row = k*block;
    73            C[row+i] = b.unpackDouble(SIZE);
    74          }
    75        }
\end{verbatim}
}
}
\end{figure}

The program initializes its IceT environment and spawns {\tt
NUM\_SLAVE} copies of the {\tt Slave} program (lines 17-27).  Problem
parameters, the slave's portion of {\bf A} and the entire matrix {\bf
B} are packed and sent to the respective processes (lines 34-52).  The
master program calculates the remaining portion of the matrix
multiplication (not shown in the listing) while the slaves 
compute their results.
Finally, all the slaves' computations are collected by the master and
the matrix is processed (lines 68-75).

The slave program (not listed) is organized in a similar form; it
completes its initialization of the IceT environment like the master
program and waits to receive buffers containing the {\bf B} matrix
and those rows of the {\bf A} matrix that it is assigned. Each slave
then computes its respective portion of the matrix multiplication,
packs up the results, and returns them to the master program.

This matrix multiplication example is intended to
demonstrate the suitability of IceT for traditional
parallel/high-performance applications.  Additionally, this example
shows the consistency with traditional distributed computing
programming interfaces of the IceT programming interface, which holds
a strong similarity to the existing programming interfaces of
PVM and MPI\cite{MPI}.  However, IceT provides some
additional features that facilitate the above task. Noteworthy aspects of the
matrix multiplication problems which are unique to IceT include:

$\bullet$\quad Copies of the IceT {\tt Master} and {\tt Slave} programs need
not be provided to each of the computational resources in the user's
IceT environment.  In the absence of finding a process locally, IceT
manages the task of locating the process and uploading it to the
appropriate resource(s) as necessary.

$\bullet$\quad In PVM, the user must supply a
compilation of the program for each distinct architecture of the
resource pool.  In IceT, any process can be freely ported and executed
within the IceT environment.  By using the system-independent language
of Java, processes enjoy a wide breadth of architectural freedom.

For performance benchmarks which compare the native IceT/Java matrix
multiplication above with variations of equivalent {\tt C} and PVM
implementations, see \cite{benchmarks}.  Preliminary investigations
show that a mixture of distributed computational processes, written in
a native language such as {\tt C} and supported by the scaffolding of
IceT, can provide performance very competitive with the equivalent
PVM implementation.

\subsection{{\em Just-In-Time}\/ Process Installation}
The focus of the matrix multiplication example was to show
that IceT adheres to traditional mechanisms of distributed computing,
thereby facilitating its use via well-understood 
message-passing parallel programs. In addition,
IceT possesses additional benefits in process/data portability and
in bringing together unrelated or external resources.

As in traditional distributed computing, local processes in IceT can
be executed on semi-local resources (as described in the first
section).  This paradigm is extended in the IceT environment to
further allow local processes/data to be uploaded to remote, unowned
resources (a colleague's system, for example), to locate remote
processes/data and to download them locally, or any dynamic
combination thereof.  Processes themselves have the ability to port
themselves amongst the resources of the environment provided they
adhere to the security imposed thereon.  All processes possess the
ability to maintain persistent communication with all other processes
within the IceT environment, with communication to
restricted elements of the environment, governed by the security
imposed upon the resources involved.  The degrees of portability,
local execution of anonymous processes, and permitted communication
channels are also governed by the security measures imposed by the
owner of the local resource.

``Just-in-time'' process installation, also referred to as
``soft-installation,'' refers to the ability for a process to enter a
resource, perform its computation within the restrictions imposed by
the environment, and to leave no residual\footnote{Leaving files
associated with the process on the local filesystem, for example.} of
the process upon termination or migration from the resource.  In IceT,
a process has the ability to upload itself to a remote resource,
become instantiated as a separate thread of execution\footnote{This
thread can be started, stopped, re-prioritized, or even serialized and
possibly ported elsewhere or archived for postponed execution --- all
governed by the local IceT environment and its configuration by the
owner of the local resource.}, complete its computational task, and
terminate only to be garbage-collected by the JVM.  Moreover, this may
be accomplished without accessing or storage of bytecode onto the
filesystem.  This process may also communicate with the various
entities enrolled in the conglomerate IceT system without actually
opening direct socket connections or being made aware of the ports
these entities are listening on.  If stringent communication measures
are imposed upon the process, the local IceT daemon governs and
manages the routing of communication to permitted external entities.

\subsection{Examples of Just-In-Time Installations}
The usefulness and utility of the just-in-time installation of
software has several immediate application areas:  

$\bullet$\quad In the simplest sense, just-in-time installation of software
could be used for local and remote {\em data mining}.  In the
situation where the data pool is quite large and the data of interest is
relatively small, transference of the data for subsequent parsing
or manipulation would take more time than porting of software
which would parse the data and return select data of interest or possibly
some visualization of the representative data.  

$\bullet$\quad As a facilitating environment for collaboration, the
just-in-time installation of software would mean that any person would
be able to utilize a vast collection of collaboration software with
fellow collaborators.  In the event that software necessary for
collaboration is lacking from a colleague's local system, the
requisite software could be uploaded to that colleague for subsequent
execution and involvement in the collaboration\footnote{For a detailed
example involving the steps involved the distribution and
instantiation of an actual IceT collaborative tool,
see\cite{benchmarks}.}.  IceT provides the substrate upon which
collaborative tools would be uploaded and provides the subsequent
channels through which these tools would be allowed to communicate.


\section{Comments on Related Work}
There has been considerable progress relating to distributed or
collaborative computing using Java \cite{alexandrov,chen,fox}. However,
the portability and accessibility of processes hasn't truly been
exploited to the level realized in IceT.
IceT shares limited similarities with JavaPVM\cite{JavaPVM}, and
JPVM\cite{jpvm}, and has attributes similar, by design, to PVM.
The objective of IceT was to take the traditional features of
distributed computing, like those found in PVM, and to extend them to
include additional features such as the merging of virtual machines,
the dynamic uploading of processes across virtual machines, etc.  Both
JavaPVM and JPVM address programming aspects and objectives orthogonal
to those of IceT, and hence offer features not found in IceT.  JavaPVM
provides a Java interface to PVM software.  JPVM is a PVM-like class
library implemented in and for use with Java.  Like IceT, JavaPVM and
JPVM provide users with an environment suitable for distributed
computing.  However, IceT's environment provides the additional
functionality of harnessing and merging with remote resources where
the user lacks privileges, and directly supports the uploading of
processes and data upon aggregated resources.




\section{Conclusion}
Through IceT, novel ideas from the domain of Internet programming have
been incorporated into the realm of distributed computing.  As a
consequence, users are provided a wider breadth of resources,
far-reaching access to processes and data, and an environment
well-suited for distributed computing, collaborative computing and
multi-user interaction.  While IceT is in its relative infancy, the
additional attributes brought to distributed computing as illustrated
by IceT are quite promising.

{\small
\begin{thebibliography}{99}
\bibitem{alexandrov} \textsc{A.~Alexandrov, M.~Ibel, K.~Schauser and
C.~Scheiman}, {\em SuperWeb: Research issues in Java-based global
computing}. Concurrency: Practice and Experience, Vol 9(6),
pp.~535-553, June 1997. 
\bibitem{chen} \textsc{M.~Chen and J.~Cowie}, {\em Java's Role in
Distributed Collaboration}.. Concurrency: Practice and Experience, Vol
9(6), pp.~509-519, June 1997.
\bibitem{jpvm} \textsc{A.~Ferrari}, {\em JPVM}.  Software package and
further information is available at  \\
{http://www.cs.virginia.edu/$\sim$ajf2/jpvm.html}
\bibitem{fox} \textsc{G.~Fox and W.~Furmanski}, {\em Java for parallel
computing and as a general language for scientific and engineering
simulation and modeling}, Concurrency: Practice and Experience, Vol
9(6), pp.~415-425, June 1997.
\bibitem{PVM}
\textsc{G.\ A.\ Geist and V.\ S.\ Sunderam}, {\em The PVM system:  
Supercomputer level concurrent computation on a heterogeneous
network of workstations}, Proceedings of the Sixth Distributed Memory 
Computing Conference, IEEE, April 1991, 258-261.
\bibitem{IceT1}
\textsc{P.~Gray and V.~Sunderam}, {\em The IceT Framework for
Metacomputing}, Document available at \\
{http://www.mathcs.emory.edu/$\sim$gray/IceT3.ps}
\bibitem{benchmarks}
\textsc{P.~Gray and V.~Sunderam}, {\em The IceT Environment for 
Parallel and Distributed Computing}, To appear in Proceedings of
ISCOPE97 (Springer Verlag), Marina del Rey~~CA, Dec.~1997.
\bibitem{MPI}
\textsc{M.~Snir, S.~W.~Otto, S.~Huss-Lederman, D.~W.~Walker, 
and J.~Dongarra}, {\em MPI, The Complete Reference}.  MIT
Press, November 1995.
\bibitem{JavaPVM} \textsc{ D.~Thurman}, {\em JavaPVM}.  Software
package and further information is available at \\
{http://homer.isye.gatech.edu/chmsr/JavaPVM/}
\end{thebibliography}
}
\end{document}
