\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.