\section{Hive}
\label{hive}

Hive is a decentralized distributed mobile agents platform designed
for ``Things That Think''.  Hive enables connectivity for devices,
allowing interactions without substantial reengineering, and creation
of interactions that needn't be anticipated at the time of the design
of the original devices.

\subsection{Architecture Overview}

The Hive architecture is composed of three pieces and a lookup scheme
to connect them.  First, there are Hive ``cells'', or servers, which
are the environment in which Hive runs.  They provide the
infrastructure for locating resources, basic agent mobility and a
bootstrap for initiating inter-agent communications.  Second, there
are Hive ``shadows'', which are essentially device drivers for local
resources, whether that may be a display, a piece of hardware, or any
other manageable local resource.  Third, Hive ``agents'' are the
pieces of mobile software that engage in all communication and
interact to create applications.  Finally, a combined
syntactic/semantic lookup scheme provides a mechanism for agents to
discover shadows and each other via a remote method provided by the
cells.  A visual representation of the Hive architecture appears in
Figure \ref{hivearch}.

\begin{figure}[hb]
\begin{center}
\mbox{\epsfxsize=3in \epsfbox{hive.ps}}
\end{center}
\caption{The Hive Architecture}
\label{hivearch}
\end{figure}

% \marginbox{Margin boxes are pretty cool!}

\subsubsection{Cells}

A Hive cell\footnote{``Hive cell'' and ``Hive server'' are often used
synonymously.  The term cell was chosen to make clear the fact that
Hive is a completely peer-to-peer system.  The label ``server''
implies a distinct client, which does not exist in Hive.} provides a
minimal interface to enable communication between agents and to allow
agents to access local resources.  Figure
\ref{cellmethods} shows the primary methods provided by a Hive 
cell.\footnote{A number of utility methods are not included in this list.}  
The first two methods, {\tt getAddress()} and {\tt
queryAgents(\ldots)} are the only methods that are accessible
remotely.  These allow remote components to discover agents in the cell.
The second group of methods relate to management of the agent life cycle
and mobility, and the last two methods provide access to the local
resources known as shadows.

\begin{figure}[hbt]
\begin{Code}
 public class Server 
    public CellAddress getAddress();
    public DescSet queryAgents(Object sender, 
                               String[] syntactic, String[] semantic)

    public boolean acceptAgent(byte [] agentBytes, Object token)
    public AgentImpl createAgent(Class agentClass);
    public boolean moveAgent(AgentImpl agent, CellAddress address) 
    public void killAgent(Agent agent);
    public synchronized AgentImpl handleNewAgent(final AgentImpl agent);

    public ShadowDB getShadowDB();
    public DescSet getShadowDescriptions();
\end{Code}
\caption{Methods on a Hive Cell}
\label{cellmethods}
\end{figure}

\subsubsection{Shadows}
\label{shadows}
Shadows provide a software interface to a local resource, typically a
piece of hardware.  The responsibilities of a shadow are small, so as
to avoid pitfalls related to security, particular application
concerns, and maintainability.  A shadow exposes an API to access the
functions of the device.  It is responsible for managing concurrent
access to the device as well as protecting the device.  It should not
be possible to damage or otherwise harm a device, despite the
sequence, timing, or parameters of calls to the shadow.  Finally, a
shadow is self-describing.  This is described in more detail in
Section \ref{semantic}.  Beyond this, a shadow should be as minimal as
possible.

\par

The shadow model helps maintain a strong distinction between local
resources, and remote operations\cite{Waldo+97a}.  In this capacity,
it provides added security as well, which is necessary in an
environment where full agent mobility is possible.  In a traditional
sand box or capabilities-based security model, a given agent could be
restricted from communicating with hardware, or only to particular
hardware, but neither of these models is well suited to constraining
the actual contents of that communication.  For example, a motor
controller may be connected via a serial port.  While a sand box or
capabilities based model could prevent communication with other
devices, there would be nothing to prevent an agent from overdriving
the motor.  With a shadows based abstraction, all communication with
local resources is mediated.

\subsubsection{Agents}


Agents are pieces of mobile code that reside in cells, locate and
export or otherwise utilize the functions of shadows, and communicate
with other agents.  Applications built on top of the Hive architecture
are constructed as a set of interacting agents, or a so-called
``distributed ecology of agents''\cite{ecologyofagents}.  Some agents
will essentially be direct proxies for shadows, while others will be
pure software services, and yet others will coordinate the behavior of
other agents.

\par

By their mobility, agents can readily be used to modify the
abstraction by which a device is operated.  A camera can be changed
from a image exporter to a motion detector by sending a new agent to
communicate with the camera shadow.  The details and implications of
Hive as a mobile agents system are discussed in more detail in
\cite{ollie} and \cite{hivepaper}.

\subsubsection{Lookup}

In a small scale system, hard coding the connections and interactions
is reasonable, but as a system gets larger, it becomes desirable to
have a scheme for dynamically creating these connections.  This is
accomplished in Hive via a combined syntactic and semantic lookup
scheme.

\par

The distinction between syntactic and semantic lookup is intended as
follows: An agent or shadow is {\em syntactically} described by its
programmatic interfaces or API, and the {\em semantic} description is
composed of qualities that are not accessible via the objects API,
such as (in most cases), location, physical description, or ownership.
In Hive, syntactic lookup is tied to the Java type system,
specifically to the {\tt Remote} interfaces of the object in the case
of agents.

\par

In all cases, the user of the lookup system is an agent, though the
objects being looked up may be agents or shadows.  The cells form a
default form of federation, where it is possible to locate all of
the agents inhabiting a particular cell by using the {\tt
queryAgents(\ldots)} method on the cell.  Other agents may collect
these descriptions and generate other federations, such as a larger
area federation, or those based on syntactic type or based on a
particular of the semantic description.

\par

The semantic lookup scheme is described in detail in Section
\ref{semantic}, and compared with Jini's\cite{jini}
attribute\cite{jiniattribute} based lookup scheme in detail in Section
\ref{jini}.


\subsection{Implementation}

The Hive system is implemented in Java\cite{javabook}, using JDK
1.1.7\cite{jdk117}.  In excess of 22,000 lines of code have been
written for Hive with under 10,000 lines composing the core of the
system, and the remainder being application agents and shadows.  Hive
utilizes a number of third party packages as well:
SiRPAC\cite{sirpac}, AElfred\cite{aelfred} and SAX\cite{SAX} for
processing of XML-encoded RDF files, and javax.comm\cite{javacomm} and
rxtx\cite{rxtx} for serial communications.  Figure \ref{hiveui} shows
the GUI for Hive (which is itself an agent).  Each icon represents an
agent, and lines between agents imply connectivity between those
agents.

\begin{figure}[hbt]
\begin{center}
\mbox{\epsfxsize=3in \epsfbox{hiveui.ps}}
\end{center}
\caption{The Hive Graphical User Interface}
\label{hiveui}
\end{figure}


\subsection{Applications}

Hive was released internally within the Media Laboratory in January,
1999.  A number of applications were built with Hive, including the
primary application discussed in this work, the networked kitchen,
which is discussed in detail in section \ref{netkitchen}.  Other
applications included the ``Honey, I Shrunk the CDs''
scenario\footnote{Described in section \ref{scenarios}.}, a set of
interfaces by the Tangible Media Group, a vision system and
electrostatic tracking system for a MOMA installation, a personal
location service for wearables\footnote{Also described in section
\ref{scenarios}.}, and a number of sample applications developed by the
Hive developers.

\subsection{Summary}

The Hive system has been built and addresses many of the problems
associated with constructing networks of things that think.  The core
architecture has proved flexible and useful in a number of particular
applications discussed in the following sections.