\section{Design}
\label{sec-design}

The design of {\kf} has the following goals:

\begin{itemize}
\item
{\em Maintaining ease of use:} {\kf} should work with standard
browsers and comply to Java standards.  In particular, users should
not be burdened with additional administrative efforts such as locally
installing software packages.

\item
{\em Maintaining secure environment:} The system security should not
be jeopardized.  This means that both native code and browser plug-ins
should be avoided.  In hindsight, this is an unresolved issue and will
be further discussed in Section~\ref{sec-security}.

\item
{\em Scalability:} Since {\kf} targets computing over the World Wide
Web, scalability is a consideration.
\end{itemize}

To take full advantage of today's technology, parts of the application
designed to execute on remote machines are generally implemented as
applets.  The code to execute on a user's local machine is implemented
as a stand-alone Java application which is not under scrutiny of the
applet security model. In this paper, we call the combination of a
stand-alone application and applets a \emph{distributed computation},
a particular invocation of this a \emph{session}, an invocation of the
stand-alone application an {\em initiator}, and applets belonging to
the same session \emph{partners}.  This scenario is the setting for
{\kf}.

\begin{figure}[tbp]
% \centerline{\includegraphics{.eps}}
% * means clipping
\centerline{\includegraphics*[width=\columnwidth]{kf-arch.eps}}
\caption{Layered design of {\kf}.  It supports distributed
applications, as well as functioning as an infrastructure for other
higher-level environments.
\label{fig-arch}
}
\end{figure}

While many of the systems surveyed in the previous section provide
high-level functionality to programmers and users, {\kf} is concerned
with providing the infrastructure of such systems.
Figure~\ref{fig-arch} shows the layered design of {\kf}.  In
Section~\ref{sec-kfserver} we show how it can be used to support
parallel programming environments, and as an example, we extend
Charlotte's capabilities.  In Section~\ref{sec-kfapplet} we show how
it can directly support collaborative applications.

The design of \kf{}'s three services, {\kfdirectory}, {\kfserver}, and
{\kfapplet} is outlined below.
 


\subsection{Registration and Lookup --- {\kfdirectory}}
\label{ssec-des-reg}

Distributed applications are generally easier to build and use when a
lookup- or directory-service is available.  While there are many
classical solutions for this, for example CORBA name servers, our
focus is to provide a light-weight solution for the Web.  In
particular, we aim (1) to allow lookups from within a browser, (2) to
use the Web-infrastructure as much as possible, (3) not to introduce
new daemon processes for performing this service, and (4) to
accommodate highly dynamic registration and deregistration of entries
to support short-lived sessions.

A popular directory service is the Lightweight Directory Access
Protocol (LDAP)~\cite{rfc2251-ldap}.  It specifies both a global data
model and a protocol for clients and servers to access and maintain
this directory.  The servers perform search requests on clients'
behalf.  Our goal is to accommodate a large number of client requests
for highly dynamic directory entries.  The dynamics of the directories
makes replication of information among distributed directory servers
unattractive because of frequent invalidation. But without
replication, the servers would have to perform considerable work to
service the requests for a large number of clients. Therefore it is
not feasible to perform the search within the servers, and
consequently, LDAP-based directories are ill-suited for this scenario.
We chose to pursue a solution which executes the search within a
client's browser.

Using dynamically loaded applets to realize a directory service is
also not feasible.  Consider an applet sent from host $A$ and
executing within a browser on host $B$.  The applet can establish a
network connection only to host $A$.  If the user at $B$ is interested
in performing a directory service lookup, it is either the case that
(1) host $A$ acts as a single central directory service for this and
all other sites, or (2) host $A$ performs the search on behalf of $B$,
or (3) the directory information is replicated and synchronized on
multiple sites---neither option is acceptable.

In {\kf}, we build upon existing HTTP servers to act as
\emph{directory servers}.  Such a directory (1) stores information
about sessions looking for prospective partners (such as the URL of
the initiator, comments, \emph{etc.}), and (2) maintains a list of
other \kfdirectories{}, which can be interpreted as the edges of a
directed graph of \kfdirectories{}.  Adding and removing of both,
sessions and directories can be done using standard protocols (HTTP
Post and CGI scripts).

Our technique to support lookup operations is unique.  A lookup can be
initiated at any server which offers a {\kfdirectory}.  By including a
JavaScript program along with a session and directory list in a single
HTML page retrieved from such a server, a browser can inspect this
information and, if a matching session is found, proceed to the
respective URL, otherwise use the directory list to search recursively
at another site.  By passing along state information as part of the
URL of the next directory, search strategies like breadth-first search
can be implemented.
%Breadth-first search is preferable to find
%sessions on nearby hosts first, assuming that nearby applications
%exhibit better communication efficiency than more remote ones.

%The combination of these techniques allows the search to be performed
%in the client's browser, putting only minimal strain on directory
%servers.


\subsection{Arbitrary Origin of Applets --- {\kfserver}}
\label{ssec-des-arborg}

In a typical distributed Java application, applets are loaded from an
HTTP server and connect to a stand-alone application, the initiator
(see Figure~\ref{fig-routing}).  Among others, this is the case for
applications written in Charlotte, Javelin, and the Java Collaborator
Toolset.  The Java security model dictates that the initiator has to
run on the same host as the HTTP server.  Ideally, however, initiators
should be able to execute anywhere on a network.
   
{\kf} addresses this problem by providing a light-weight HTTP server.
{\kfserver} implements the essential functionalities needed to serve
applets, and is designed to be embedded into any Java application.  As
a result, it is the application itself which dynamically serves
classes to browsers upon request.  Although quite simple, this makes
it possible for initiators to run on any host connected to the
network.


\subsection{Direct Applet-to-Applet Communication --- {\kfapplet}}
\label{ssec-des-direct}

Browsers impose their own restrictions, specifically the {\em
host-of-origin} policy, to safely execute a piece of code loaded over
the network.  In short, browsers disallow applets from establishing a
network connection except to the host where they were loaded from.
This has hampered the ``collaborativeness'' of applets.  Typical
solutions to allow applets to exchange information have been to either
rely on {\em untrusted native code} or to use {\em a single forwarding
agent}.  Untrusted code has been used as native-methods~\cite{bbb96}
and browser plug-ins~\cite{tango}.  However, this approach breaks the
security guarantees provided by Java and introduces additional
administrative overhead otherwise not needed.  More importantly, it
prevents off-the-shelf browsers from participating in a distributed
computation.  The use of a single agent to forward messages among
applets as used in~\cite{ccinsw97b,java-collaborator,pagespace} has
drawbacks: it introduces a single point of failure, limits
scalability, and might raise privacy concerns when messages should
not be subject to inspection by a forwarding agent.

JDK~1.1 introduced signed applets and JAR files using a
certificate~\cite{secure-comp-java,java-jdk12}.  In JDK~1.1, once a
signature is recognized and trusted, a signed applet is treated as
trusted local code.  For future releases~\cite{java-jdk12}, Java
promises permission specifications and fine-grain access control.  The
Java runtime is to maintain a mapping from a {\em code source} (i.e.,
the URL location and a corresponding certificate) to a {\em protection
domain} and then to user-defined permissions.  This way, a user can
define the permission of executing code and selectively override the
host-of-origin policy by trusting certain code-providers.  But the
process of contacting a certifying authority for a certificate is a
tedious process for most casual application developers.  {\kf}
provides a flexible solution without burdening the user with the
problematic choice of where to put trust, and without burdening the
developer with obtaining a certificate.

{\kfapplets} use Remote Method Invocation (RMI)~\cite{wrw96} of Java
1.1 to realize direct applet-to-applet communication.  RMI is based on
a client/server architecture; once a client obtains a reference to a
remote server object it can invoke server methods.  In our design,
each {\kfapplet} creates such a remotely accessible object and passes
its reference to the initiator.  In the simplest case, the initiator
redistributes the references back to all other applets.  Thus, every
{\kfapplet} belonging to the same session can invoke others' methods
and thereby communicate arbitrary data through method arguments.  


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