For networks of ubiquitous devices to become reality, they must run with a minimum - and preferably zero configuration. That is, it should be possible to add devices to a network by doing nothing more than plugging them into a power supply (if needed) and just switching them on. Similarly, removal should be done by just switching them off. The current mechanisms for configuring devices in a network are (a) by hand; (b) placing the burden on a netork service such as a DHCP server (which also needs configuration); or (c) using techniques of zero configuration.
While zero configuration plays an important role, it only manages how the device is known to the network and how it can communicate with other devices in the network. However, devices are used for a purpose, and that is generally to provide some sort of service. In order to be effective, zero configuration needs to be applicable at the service level, so that devices/clients/services can find other devices/clients/services and make use of them.
There are many service advertisement and discovery systems and these are discussed in the next section. However, in this paper we concentrate on the Jini middleware, which was designed for the management of adhoc services. On the face of it, Jini should be very suitable for a zero configuration environment. However, we show in this paper that Jini needs some changes: in specifications, in reference implementations and in the discovery structure of the middleware.
We show in this paper that Jini is almost suitable, both to run in zero configuration networks and to require zero configuration itself.. However, it needs changes to specifications, implementations and needs more flexibility in the advertisement architecture.
The IETF Zeroconf working group has established four attributes of zero configuration networks:
Each host on an IP network must have an IP address, which can be hard-coded, found from a DHCP server, or be self-assigned as a link-local address. By this means, a host in any IP network can get an IP address. Similarly, names may be hard-coded, found from a DNS server or be self-assigned. Service discovery is addressed by SLP (Service Location Protocol) which is considered later.
There are a large number of service systems, with a variety of ways of advertising and discovering services. Such ways include "naming service" advertisements where services register with a separate "well known" naming service. Such systems include RMI, CORBA and in the future, Web services with UDDI registries. Such systems require configuration of the naming service, and so are not entirely suitable for zeroconf networks.
UPnP (Universal plug and play) avoids this issue by each device/service advertising itself directly by multicast to all potential clients. Part of each advert is a URL where further information about the service can be found, and it is expected that each device/service will run an HTTP server.
SLP also advertises directly by multicast, but is most cases the advert contains enough information to invoke the service without requiring further information. Both UPnP services and SLP services are adapted to zeroconf networks.
Jini on the other hand is not. A lookup service is required, playing an object-oriented equivalent to a naming service. In addition, Jini downloads objects from service to client and this not only requires instance data but also class files. These class files are typically located on an HTTP server. Running a Jini service typically requires an environment already containing lookup services and HTTP servers.
The Jini specification only requires that all hosts have IP addresses in an IP network.
It does not require host names. The Jini 1.2 implementation however is heavily dependant
on names as it does a name to address resolution in order to find the local host IP
address. In Jini 2 this dependency has been largely removed, and it is possible to configure
a Jini service so that it takes its address from the local host without a name to address
lookup (modulo a minor bug in the LookupDiscovery class).
It is thus possible to run Jini in a zeroconf eonvironment, using hard-coded, DHCP or self-assigned link-local addresses.
A UPnP device is expected to run an HTTP server along with all its own device services. A Jini service may be running on a host that is not running an HTTP server, and indeed, there may be no HTTP servers running that are accessible. In addition, even if there was an HTTP server running, a deployment step would require that class files be copied to the server.
This can be avoided by each Jini service running an HTTP server of its own. That is,
as part of Jini service startup, it sets an HTTP server running where the server root
contains the service's remote class files. The service can then set its own
java.rmi.server.codebase property based on its host name (if available)
or IP address and the chosen HTTP port.
In a standard Jini environment, both services and client send multicast requests for a lookup service. Any lookup service getting this request will reply. After this a unicast conversation follows, in which services upload a service description to the lookup service and clients download this description. If there is no lookup service present, then clients and services cannot find each other.
The standard Jini lookup service from Sun is called "reggie". We have implemented a "half reggie" which runs from within a service. A Jini service tries to find a lookup service (or "full reggie") in the usual way. If it fails after some suitable timeout, it starts up its own half-reggie. The service registers itself directly with this half-reggie. The half-reggie will respond to requests from clients and services by engaging in a unicast conversation and sending a registrar proxy as usual. If a client requests the service registered with the half-reggie then this is also sent to the client in the normal way. A client just sees the half-reggie as a normal Jini lookup service.
A separate service may also locate a half-reggie lookup service and attempt to register with it. An implementation choice could allow this to succeed, or it could deny it. Either way if okay. If the half-reggie accepted external requests then it would be acting like an ordinary lookup service with a short-cut for registration of the local service. On the other hand it could deny such an attempt, to keep memory usage to a minimum. Our current implementation takes the second course, and the implications of this are discussed later.