\section{Related Work}
\label{sec-related-work}

There is a growing body of work on how to best utilize the emergence
of new Java-based technologies.  This work can be loosely categorized
based on their emphasis: those that focus on parallel programming
environments, or {\em metacomputing on the Web}, and those that focus
on the infrastructure for {\em collaborative applications on the Web}.


\paragraph{\bf Metacomputing on the Web:}

The projects which focus on Java-based parallel computing include
ATLAS~\cite{bbb96}, Charlotte~\cite{bkkw96},
%Java-MPI~\cite{tay}, JPVM~\cite{fer},
% I removed it since the references are no longer valid (web pages not found)
JPVM~\cite{fer}, JavaParty~\cite{pz97}, Javelin~\cite{ccinsw97b},
ParaWeb~\cite{bbst96}, and WebFlow~\cite{bbcffp}.  Similarly, there
have been proposals for Web-enabled virtual machines as a base for
High Performance Computing and Communication (HPCC)
platform~\cite{ff96}, to use Java in an SPMD programming
model~\cite{hns97}, and to extend Java with global pointers and remote
service request mechanisms from the Nexus communication
library~\cite{ft}.  Unfortunately, all but Charlotte and Javelin fail
to take advantage of Web browsers in bringing distributed computing to
every-day users.

JPVM provides a message passing interface to Java stand-alone
applications, but not applets.  Projects such as JavaParty
and~\cite{hns97} require running a Java process to act as a runtime
environment (in the case of JavaParty, this process is called the {\em
LocalJP}).  ParaWeb includes a distributed implementation of the Java
Virtual Machine.  ATLAS programs are load-balanced using work-stealing
scheduling but rely on native code which eliminates the secure program
execution guarantees.

\begin{figure}[tbp]
%\centerline{\includegraphics*{routing.eps}}
\centerline{\includegraphics*[width=\columnwidth]{standard.eps}}
\caption{Architecture of a typical Web-based parallel or 
collaborative computing system.  
\label{fig-routing}
}
\end{figure}

Charlotte and Javelin were specifically designed for parallel
programming over the Web.  By leveraging the ability of browsers to
download and execute remote applets, they provide the means for any
user, anywhere on the Internet, using any Java-capable browser to
participate in a parallel computation.  The essence of their system
architecture is shown in Figure~\ref{fig-routing}.  A single host, the
server in the diagram, runs a Java stand-alone application and an HTTP
server.  Other hosts load applets which reside on the server and
execute them within a browser's secure environment.  It is important
to note that all applet-to-applet communication is routed through the
stand-alone application running on the server.

There are two features common to the design of Charlotte and Javelin.
First, they require a host running an HTTP server in addition to a
stand-alone Java application.  In Charlotte, the stand-alone
application is called the {\em manager} and there is one manager per
parallel program; in Javelin, it is called the {\em broker} and a
broker may serve multiple programs at a time.  The role of the
stand-alone application is to distribute work among browsers and to
act as a message forwarding agent for applet-to-applet communications.
A single forwarding agent has the potential of becoming a bottleneck.
The second commonality is that users need to have {\apriori} knowledge
of the host running the stand-alone application.


\paragraph{\bf Collaborative applications on the Web:}

The second category of projects focuses on software infrastructures
for collaborative applications.  Examples of such applications are
distributed whiteboards, calendars, and editors where multiple users
collaborate towards one goal.  High-level software systems which
support collaborative Java applications include the Caltech Infosphere
project~\cite{infosphere}, Jada/PageSpace~\cite{pagespace}, Java
Collaborator Toolset~\cite{java-collaborator},
JavaSpaces~\cite{javaspaces}, and TANGO~\cite{tango}.

Jada and JavaSpaces integrate the Linda concept with Java.  Where Jada
uses a Linda-like tuple model, Java\-Spaces utilizes object hierarchies
for tuple matching.  PageSpace builds higher-level functionalities on
top of Jada.  Infosphere proposes channel-coupled agents to build
flexible ways of collaborative interactions. These systems utilize
Java for building stand-alone applications and do not take advantage
of browsers.  For example, while users interact with a PageSpace
application in a browser, the actual collaboration is provided by a
set of processes which must be started beforehand.

TANGO provides functionalities such as session management, user
authentication, event logging, and communication between collaborative
users.  The main two elements of TANGO's architecture are a {\em local
daemon} and a {\em central server}.  The local daemon is implemented
as a Netscape plug-in to circumvent restrictions put on applets, and
hence, breaks the security guarantees.

Java Collaborator Toolset provides a replacement for Java's standard
Abstract Window Toolkit (AWT).  The replacement package propagates AWT
events to all collaborating agents.  However, this is done through a
central {\em event distributor}, similar in design as depicted in
Figure~\ref{fig-routing}.

While the functionality of these metacomputing and collaborative
systems transcends {\kf}'s goals, {\kf} can provide a flexible
infrastructure for them.  First, {\kfdirectory} can provide the
mechanism for users' browsers to search the Web for work.  Second,
{\kfserver} can be used to run initiators on machines other than a
common HTTP server machine.  And finally, {\kfapplet} can support
direct applet-to-applet communication avoiding a potential for a
bottleneck.


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "paper"
%%% End: 
