\section{Implementation of {\kfapplet}}
\label{sec-kfapplet}

This section addresses the issue of how to facilitate direct
communication among multiple applets belonging to the same session and
why this is beneficial.  The security concerns regarding such
inter-applet communication will be discussed in
Section~\ref{sec-security}.

Our approach is based on the RMI interface of Java 1.1.  \kfregistry{}
implements the functionality of an RMI registry.  A \kfregistry{}
object is a remote object which registers with its own registry during
startup of the initiator (see Figure~\ref{fig-appapp}, step 1).  A
joining applet retrieves a remote reference to this object (e.g.,
after finding the initiator through \kfdirectory{}) from the RMI
registry\footnote{Note that this is possible since the applet was
downloaded from this very machine using, e.g., the \kfserver{}.} (step
2), and invokes a remote method of
\kfregistry{} to inform the registry of its presence, passing along a
reference to itself (step 3).\footnote{It is of course possible to
include security checks, e.g., a password, in this registration call.}
\kfregistry{} stores this reference and returns references to already
registered \kfapplet{}s to the joining applet (step 4).  Finally, the
new applet registers itself with all other applets, passing alone a
reference to itself (step 5).  After this, all applets know about each
other and can invoke remote methods among each other.

\begin{figure}[tbp]
\centerline{\includegraphics*[width=\columnwidth]{appapp.eps}}
\caption{Registration protocol for applet-to-applet communication. 
\label{fig-appapp}
}
\end{figure}

After this bootstrapping phase, the \kfregistry{} is no longer
needed---applets can use their mutually known references to invoke RMI
calls at each other and thereby communicate directly without using the
initiator in any way.  This removes the initiator as a potential
bottleneck since it is only involved during the bootstrapping phase,
and the latencies experienced by users of a collaborative application
should be much lower compared to an approach using a forwarding agent.
For example, consider two participants in Europe cooperating via an
applet originating from a server in North America.  \kf{} provides the
{\tt KF\_Applet} class as a convenience wrapper which hides the
details and allows remote method invocation at other participating
applets; the initiator has only to instantiate an object of class {\tt
KF\_Manager}.


\subsection{{\kfapplet} and Collaborative Applications}
\label{ssec-whiteboard}

To demonstrate the viability of the \kfapplet{} concept, we have
implemented a shared whiteboard.  The changes necessary to turn a
stand-alone whiteboard into a shared version are few and
straightforward.  First, the whiteboard applet was derived from {\tt
KF\_Applet} instead of {\tt java.awt.applet}.  Second, we implemented
a set of remote methods to handle AWT events.  And finally, we
explicitly added RMI calls to propagate AWT events to all partners of
a collaborative session.  Unlike~\cite{java-collaborator}, {\kf} does
not require re-implementation of the AWT package or a centralized
forwarding agent.  Also, it is worth emphasizing that the whiteboard
applets continue to work even if the \kfregistry{} process is
killed---they communicate directly via RMI and do not require a
forwarding agent.

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