\section{Introduction}
\label{sec-intro}

The World Wide Web has the potential of integrating remote and
heterogeneous computers into a single global computing resource for
parallel and collaborative work.  While parallel computing on
workstation clusters is common practice with systems such as
PVM~\cite{Sunderam:PVM:94} and MPI~\cite{GLS94}, this is not the case
for computing over the Web.  Similarly, while collaborative work on
intranets is supported by systems like CORBA~\cite{corba97} and
DCOM~\cite{BK96}, this does not hold true for the Web.  Some of the
obstacles common to both Web-based parallel computing and
collaborative work are the heterogeneity of the participating systems,
difficulties in administering distributed applications, security
concerns of users, and often high communication delays.

The combination of the Java programming language together with
Java-capable Web browsers has successfully addressed some of these
problems.  Java's platform independence solves the problem of
heterogeneity.  The growing number of Java capable browsers able to
seamlessly load applets from remote sites reduces administration
difficulties.\footnote{Consistent with Java terminology, we use the
term {\em applet} to refer to a Java program which is typically loaded
form the Internet and executed inside a browser.}  The applet security
model, which in most parts enables browsers to execute untrusted
applets in a trusted environment alleviates some of the users'
security concerns.  It is because of these reasons that Java applets
became a good candidate for building Web-based systems, and browsers
the perfect candidate to seamlessly bring distributed computing to
every-day users.

\begin{figure}[tbp]
% \centerline{\includegraphics{.eps}}
% * means clipping
\centerline{\includegraphics*[width=\columnwidth]{goodthng.eps}}
\caption{With \kf{}, applications can execute anywhere on
the network; browsers are able to locate the application;
and after a {\em bootstrapping} procedure, direct
applet-to-applet communication is possible.
\label{fig-charlotte}
}
\end{figure}

In this paper, we focus on applications composed of Java applets and
designed to run within Web browsers.  As a result of limitations put
on applets, the architectures of many existing systems have the
following characteristics: (1) a stand-alone application running on
the same host as an HTTP server; (2) users on the Internet joining a
stand-alone application by loading an applet using an a priori known
URL and executing it within a browser; and (3) each applet creating a
direct network connection to its associated application, which is
responsible to propagate information from one applet to another (see
the left side of Figure~\ref{fig-charlotte}).  In an ideal situation,
(1) the applications should not be tied to an external HTTP server and
should be allowed to execute anywhere on a network; (2) users should
not be required to have a priori knowledge of the URL and should be
able to locate these applications in a seamless fashion via browsers;
and (3) collaborative applets should be able to directly exchange
information.  The ideal scenario is depicted in the right side of
Figure~\ref{fig-charlotte}.  {\kf} is an infrastructure for building
such systems and provides three integrated services:

\begin{itemize}
\item
{\kfdirectory}, a distributed name service to assist users in finding
networked applications on unknown hosts.  {\kfdirectory} makes it
possible for the user to find such applications on the Internet by
performing a lookup at any site offering a {\kfdirectory}.  Since we
are mostly concerned with applications which register and deregister
frequently, the challenge is to provide this functionality in a
decentralized fashion, but more importantly, such that it works with
Web browsers.

\item
{\kfserver}, an embedded class server to eliminate the need of
external HTTP servers.  A user who may wish to initiate a distributed
application might not have access to a host running an HTTP server and
it may be inconvenient or impossible to install such a server on the
local host.  {\kfserver} provides a light-weight solution to allow
users to initiate a distributed effort on any host.

\item
{\kfapplet} for direct applet-to-applet communication.  The
host-of-origin policy imposed by browsers prevents direct network
connections between applets.  {\kf} is unique in providing an
infrastructure for applets of the same distributed session, executing
in multiple browsers on the Internet, to communicate and exchange
information {\em directly}.
\end{itemize}

The rest of this paper is organized as follows.  Next, we give an
overview of related projects to highlight how {\kf} can assist in
overcoming some difficulties associated with applets.
Section~\ref{sec-design} describes the philosophy and design of {\kf}.
Sections~\ref{sec-kfdirectory},
\ref{sec-kfserver}, and \ref{sec-kfapplet} describe the implementation
and example applications of the respective services.  A more detailed
description of the implementation can be found in~\cite{kf-tr:97}.  We
conclude by discussing the security implications of {\kf} and by
presenting the status and future directions of this project.


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