\section{Jini}
\label{jini}

\marginpic{jinilogo.ps}{}
Jini and Hive share many qualities.  Both are distributed software
systems designed to be simple and flexible and targeted at small
applications involving spontaneous networks of small devices.
Additionally, both are implemented in Java, and share many of the
modes of interaction that this implies.  Finally, both have a concept
of component services or agents which are mobile.  While both systems
utilize code mobility, Jini has a somewhat different paradigm of
operation: the services export their interfaces and stubs, while in
Hive there is this mode of mobility as well as the ability for an
agent to entirely move from place to place.  This section discusses
the basic Jini architecture, compares it with Hive, and explores their
differences, inter-compatibility and strengths.


\subsection{Basic Architecture}

Jini was developed by Sun Microsystems to ``enable impromptu networking
of a wide variety of devices''\cite{jinifactsheet}.  As with Hive,
Jini is implemented in the Java language, however, as it was developed
within Sun, utilized a later version of Java, JDK 1.2 (aka ``Java
2'').  Jini was initially released in January, 1999.

\par

The basic components of a Jini system are called services and clients.
These services join a Jini federation via the discovery and lookup
protocols, which are used to locate other services.  Jini also
incorporates specific notions of leases and events into its
architecture.  A client uses the discovery and lookup protocols to
locate services, but does not join a federation itself.

\par

The discovery and lookup protocols provide a mechanism for Jini
services to find one another.  ``Discovery'' in the Jini sense, is the
process of a new service locating a nearby lookup service.  This is
done by sending a broadcast or multicast packet which contains enough
information for the Jini lookup service to establish communication
with the new service.  The new service then registers itself with the
lookup service, and other services can then use the lookup services to
find it.  After this, all communication between services is currently
via RMI\cite{RMI}, though individual services may implement their own
protocol, if desired.

\par

Jini services, in addition to interacting with each other, may be
connected to directly by a client.  A client uses the discovery and
lookup protocol to find a desired service, but does not register
itself as a service.  

\par

Leases are the mechanism Jini utilizes to deal with distributed
failure.  One service's interaction with another is specified for a
limited lease time, which must be renewed.  If the other service, or
the intermediate network has failed, this lease renewal fails,
providing an opportunity for the service to gracefully respond to the
outage.

\par

Jini also defines a mechanism for sending ``Distributed Events''\cite{distevents}.
These events are closely tied to the standard Java Event Model, but
are adapted for use in a distributed environment.  Events provide a
convenient mechanism for devices to send general notifications, such
as the availability of a new service.

\par

Though not strictly part of Jini, Sun provides two standard and
generally useful Jini services: JavaSpaces and a Transaction Manager.
JavaSpaces provide a network ``location'' for interaction between
distributed components.  Requests, responses, or other types of data
may be posted in a JavaSpace for examination and potential use by
other services.  The Transaction Manager provides a way to execute
complex transactions in the face of potential failures.  This sort of
service is critical for many applications, and while it could readily
be implemented within each application, Sun chose to provide it as a
general Jini service.

\subsection{Architecture Comparison}

At a fundamental level, Hive and Jini are closely related; both are
Java based distributed object systems implemented in Java that
communicate principally via RMI, and provide mechanisms for discovery of other
services.  In a number of ways, such as Hive's notion of a cell, the
particular approach toward lookup, and how code mobility is treated,
they are quite different.

\par

Hive includes the notion of a ``cell'', in which agents and shadows
reside.  In Jini, there is no notion of collocation.  Correspondingly,
Jini lacks the notion of a shadow.  The shadow abstraction becomes
more useful when software components are fully mobile, for the reasons
discussed in Section \ref{shadows}.  Jini services can act as a proxy
for a local device, in much the same way a Hive shadow does.  In Jini,
if a full software mobility layer were added, services would have to
implement all communications with a device themselves, or an
equivalent of the shadows abstraction would have to be created.
Additionally, in Hive, all components that communicate over the
network are expected to be agents, and there is no distinct concept of
a client.

\par

In Hive, the structure of a cell provides a default discovery
mechanism.  When an agent is ``born'', it is told where (which cell)
it is, and correspondingly does not need to engage in any sort of
discovery protocol directly.  To some extent, this simply defers the
discovery problem to the level of the cells: How do cells discover one
another?  Certainly a broadcast/multicast approach such as Jini could
be utilized, or a more mobile-agents-oriented approach could be taken,
such as having ``discovery agents'' hopping from cell to cell,
identifying other cells that are known, and sharing this information
as it travels.  This does not completely solve the problem, as it
requires bootstrapping via either centralized or hierarchical
long-lived/well known cells, or via a Jini like discovery protocol.
However, even without this, the cells themselves provide a convenient
form of limited federation.

\par

The way actual lookup occurs is somewhat different between Hive and
Jini.  In Hive, each cell acts like a Jini lookup service, but
individual agents may provide lookup services for other agents
collected from multiple other cells.  Further, the Jini approach of
``Attributes'' and Hive's semantic labelling share many qualities, and
are worth exploring separately.  This comparison appears below in Section
\ref{semlabeljini}.

\par

Hive lacks Jini's feature of leases altogether, though the Jini
leasing system could be readily used within Hive with minimal changes
to Hive.  Further, Hive uses the identical distributed event model as
Jini.  Hive provides a number of default services, such as an agent
that allows creation of a user interface, a server list agent which
manages a list of currently known cells, but no JavaSpaces analog or
transaction manager is used.

\par

One of the more significant differences between Hive and Jini is the
approach taken toward code mobility.  In Hive, agents are fully
mobile, and may fully transfer their code and thread of execution to
another machine, at will.  Then, any network communication with this
agent is done via dynamically downloaded RMI stubs.  In Jini, a
service is not capable of initiating movement on its own, and only
implements the latter form of mobility.  In either case, there is
nothing to prevent the dynamically downloaded stubs from being a full
implementation of the service, rather than just an RMI proxy.

\subsection{Semantic Descriptions}
\label{semlabeljini}

Semantic descriptions in Hive play the same role as Jini Lookup
Attributes\cite{jiniattribute}.  In Jini, services are registered with
a lookup service as a {\tt ServiceItem}, which is composed of a
reference to the service, and a set of attributes.  These attributes
are Java classes.  When lookup is performed, exact match checks are
performed against the public instance variables in the attribute
classes, with null acting as a wild card.  One key difference between
this approach and the Hive system is the lack of hierarchical
descriptions.

\par

The Jini Attribute system has the advantage of being strongly typed,
due to the fact that it utilizes the Java type system.  This advantage
is lessened, however, by the lack of hierarchical descriptions.
Because of this, the fields of many attributes will be represented as
{\tt String}s, rather than actual data structures.  For example, an
object may have an attribute of ``Owner'' which has the fields
``name'', ``email'', and ``department''.  It would be convenient if
the ``department'' field could then have fields like ``supervisor''.
In the Jini attribute approach, it is necessary for the ``department''
to be a {\tt String} or equivalent for the matching to work.  Looking
up all services whose owners work for a department supervised by a
particular person becomes impossible within the lookup system.  This
requirement is mitigated by the fact that it is often easy to just
flatten such structures, but this does not scale well.

\par

As mentioned in Section \ref{semantic}, Hive's semantic labeling
system can alleviate some of the weaknesses of having no strong typing
through use of DTDs and DDML schemas.  Further, this allows Hive
descriptions to more readily interoperate with non-Java based descriptions.

\par

In Jini, the description, or attributes, is not directly tied to a
service.  Due to the fact that the attributes and the service
reference are wrapped together into the {\tt ServiceItem} bundle, it
is possible that the same service could be referred to by multiple
{\tt ServiceItem}s, each of which has different attributes.  This has
certain advantages, in flexibility, and certain disadvantages, in the
case of an object listed in multiple lookup services that wants to
make a single change.

\subsection{Compatibility}

Once Hive is moved to Java 2, it should be straightforward to allow a
Hive agent to act as a Jini service.  It would need to participate in
the discovery and lookup processes on its own, and manage leases.
Other than this, communications from other Hive agents and other Jini
services could proceed as usual, including event generating agents
using a single receiver list composed of Hive and Jini components.

\par

Similarly, a Jini service would require minimal modification for it to
be able to be instantiated inside a cell as a Hive agent.  The Jini
service would need to implement methods related to the Hive agent
life cycle.  Event oriented agents would also utilize Hive's mechanism
for event subscription, although even within Hive this is not a strict
requirement.

\par

It would be further possible to enhance Jini and Hive interoperability
by recasting the Hive cell itself as a Jini service.  This would
provide a mechanism for adding Hive-style mobility to Jini, where
services could initiate movement from one location to another.  The
cell service would provide the mobility methods and the Hive lookup
methods.  Additionally, Jini's lookup service would provide a way for
cells to initially discover one another.

\par

Without any changes, Hive an Jini share the same distributed event
model.  Utilizing this commonality may be difficult due to the
bootstrapping problem of a Jini service getting a reference to a Hive
agent or vice versa.  If this bootstrap problem were solved, however,
Jini and Hive services could readily obtain references to one another,
as both systems use the distributed event system to notify interested
parties of new agents/services.


\subsection{Analysis}

When compared to Jini, Hive has a number of advantages and
disadvantages.  Most of its advantages make it better suited for use
in a research environment, and less well suited for commercial
deployment, which is appropriate given the context of the development
of each system.

\par

The advantages of Hive include the approach toward semantic labeling,
Hive-style code mobility, and an explicit distinction between local and
network resources, in agents and shadows.  The semantic labeling
approach used in Hive is especially useful in exploration of
ontologies for the things that think domain.  By allowing arbitrarily
structured, dynamically modifiable descriptions, new techniques and
schema can be tried out somewhat more flexibly and quickly than the
Jini Lookup Attribute approach.  This flexibility is at the cost of
some added complexity, however.

\par

Hive also provides complete mobility.  This provides a number of
advantages, most of which have not yet been thoroughly explored.
Jini's stub mobility provides much of the needed features in common
application domains, and with custom generated stubs, some of the
possibilities of full mobility become available.  Further, as
mentioned above, full mobility could be added to Jini without a total
redesign.

\par

Hive explicitly includes a notion of locality.  This is necessary for
its approach toward mobility; if an agent wants to move, it needs a
place to move to.  This concept of locality allows a way for agents to
find localized resources.  Hive's shadows layer provides a standard
way for these agents to communicate with local devices, such as
described in the Jini Device Architecture
Specification\cite{jinidevarch}, but in such a way to accommodate the
mobility of the agents.  Jini can accomplish some of the same goals by
using a capability based security model for untrusted services.

\par

Jini currently has substantial advantages in terms of initial
discovery.  Hive cells have no bootstrap mechanism other than
specifying a well-known cell or cells, to join the larger network.
Additionally, Jini provides the stability one would expect from a
commercial system, in contrast to Hive's lesser stability, as would be
expected from a research system.



