A first look at Jini lookup and discovery protocols
Jini promotes the concept of a federation of services that collaborate dynamically over a network.
Jini technology builds on the Java platform and RMI to bring a new vision for distributed applications.
Jini promotes the concept of a federation of services that collaborate dynamically over a network. A service, for Jini, is essentially a Java interface. It is implemented as an RMI object. Therefore, any object could be turned into a service. Some examples of services are printing, controling a remote camera, or an electronic fund transfer.
Jini differs from other distributed architectures, such as RMI or CORBA, because it emphasizes a very dynamic approach. With Jini, as new services are plugged on the network, they immediately become available. For example, when you plug a Jini printer on the network, it is immediately possible to use it from other Jini-enabled devices such as a PC, a PDA, or even a camera.
To the developer, Jini appears as a toolbox that provides core services: how to lookup services on the network, how to download drivers, how to manage transactions, how to handle network failures, how to exchange messages, and more. Jini uses RMI as the underlying communication protocol.
In this article, we will look at two of the most fundamental core services: lookup and discovery.
The lookup service allows client and server to find each other. Upon startup, a server registers its services with the lookup service. Clients use the lookup service to locate the services they are interested in. Note that lookup is a Jini service (i.e., an RMI object).
For example, when a Jini-enabled printer is plugged in to the network, it registers itself with the lookup service. A word processor would use lookup to find available printers.
There is a chicken-and-egg problem with the lookup service: clients use lookup to find Jini services, but how do they find the lookup service itself? The answer is through the discovery protocol. Discovery is implemented through multicast and unicast requests, as well as multicast announcements.
Servers use the multicast request to locate the lookup service. Upon startup, a Jini server send multicast UDP packets to a well-known port. Multicast packets are received by every station on the local-area network. Lookup services listen on the well-known port and contact the sender, through the unicast protocol introduced in the next section, to request more information. Figure 1 illustrates a multicast request. Note that this only works on a local-area network.
Figure 1: A multicast request.
A multicast request is like shouting in an open room "Is anybody out there?" and waiting until there is an answer.
When the server knows the address of the lookup service, it can send a TCP request. The lookup service replies with an instance of ServiceRegistar -- an RMI object. Figure 2 illustrates unicast request.
Figure 2: A unicast request.
Unicast is a permanent connection and is more efficient than multicast. However, unicast only works if one party knows the address of the other. In practice, unicast is used in conjunction with multicast. For example, the lookup service uses unicast to reply to multicast requests. It acquired the address of the server through the multicast request.
Unicast is also helpful when the lookup service is not on the local-area network and could not be reached by multicast. In this case, the user must provide the address of the lookup service.
Multicast announcements are used by lookup services to announce their presence on the network when they are first connected. Servers reply with a unicast request. Figure 3 illustrates a multicast announcement.
Figure 3: A multicast announcement.
Page 1 of 2