\section{Distributed Systems}
\label{distsys}

The need for a system like Hive has evolved from experience with a
number of projects that demand useful connectivity between
things.  Hive provides a distributed system of software components
designed with the ``Things That Think'' application domain in mind.
The ``Counter Intelligence'' project in the kitchen domain that this
work is addressing has been one motivating application, but it is
worth mentioning other, earlier systems that inspired the need.

\par

The ``Marathon Man''\cite{marathonman} project involved creating a belt that collected a
variety of biometric data from a person.  While this project was
successful in doing so, it lacked a solid architecture for collecting
and presenting this data, especially for multiple simultaneous or
consecutive users.  Other projects using variants of this hardware,
\marginpic{everest.ps}{Everest Expedition team}
including the Everest Expedition\cite{everest} and the ``C2C Bike Ride''\cite{c2c} required
\marginpic{c2c.ps}{Coast to Coast Bike Ride}
re-implementing this data collection and presentation layer each time.

\par

Other projects such as the Tangible Media Group's Pinwheels\cite{pinwheels} and the
``Net Weight'' scale have suffered from the problem that despite the
fact that they are designed assuming network connectivity, this
connectivity is in fact absent.  This missing connectivity, which many
application builders have chosen not to implement, leaves the
applications unsurprisingly incomplete.

\par

Within the MIT Media Lab, there have been some projects which have
begun to address connectivity issues for things that think.  Steve
Gray's work on Bit Bags\cite{bitbags} focused on SNMP-based management of
collections of things.  The Black Box projects (Marathon Man and
Everest Expedition) addressed some of the low level issues, using a
serial hub made from an IRX\cite{irx} board, and later an I$^{2}$C bus.

\par
Outside of the MIT Media Lab, most exploration of distributed systems
has been focused on, if not confined to, software systems.
Distributed object systems such as CORBA\cite{OMG95}, OpenDoc, and DCOM are
examples.  These systems could be adapted to provide distributed
services in an environment of networked things, however there are
certain weaknesses due to the assumption that the components are
software.

\par

Sun Microsystems has developed a system called Jini\cite{jini}
described as a system that ``enables spontaneous networking of a wide
variety of hardware and software'' and as a ``distributed system
designed for simplicity, flexibility, and federation.''  Jini provides
a number of the necessary pieces for a distributed network of things.
The implications of Jini with regard to this work are discussed in
section \ref{jini}.

\par

Hive provides this needed connectivity layer.  There are three
conceptual layers to the Hive architecture.  These are the devices
themselves, a device driver layer called shadows, and the agents layer
where intentionality and applications are built.

\par

Hive is implemented in the Java language\cite{javabook} using version
1.1 of the Java API\cite{javaclass}, and from the point of view of the
Hive system, all things are considered to run Java.  In reality this
is not currently the case.  One or more Java incapable devices may be
connected to a Java capable machine that will act as a proxy for it.
The method by which these devices connect to the Java capable machine
is unimportant in terms of the Hive system.  Particularly, latency or
bandwidth considerations caused by limitations in the communication
channel are simply considered to be a limitation of the capability of
the device in question.  In practice, most Java incapable systems
communicate with the Java machine via a wired or wireless serial
communication channel.

\par

On top of the actual device functionality, there is the shadow layer.
Shadows are local pieces of code that manage access to a local
resource, usually a device.  Each shadow corresponds to a particular
kind of device, and provides a programmatic interface to the
underlying hardware, whether through an intermediate protocol or not.
Further, the shadow manages concurrent access and provides any other
mediation of access or control that may be necessary.  The separation
of the shadow and agent functionality is meant to clarify the
distinction between local access and remote communication.\cite{Waldo+97a}

\par

Finally, at the top layer of Hive is a mobile agents architecture that
allows agents to move from one computer to another, access shadows
(and correspondingly, devices) as necessary, and communicate with one
another to provide the desired application-level functionality.  These
agents are easily upgradable and modifiable by their nature as mobile
code, greatly enhancing the flexibility of the system.

\par

Hive meets the needs of this emerging class of applications of
networked devices, such as the ``Counter Intelligence'' project.  One
additional capability that is needed above and beyond this basic
connectivity architecture is a way for the devices, shadows and agents
to communicate semantic descriptions of themselves to others.  This is
described in Section \ref{semantic}.

\par