LD.1. Introduction

Part of The Jini Technology Core Platform Specification, “Discovery and Join” is devoted to defining the discovery requirements for well-behaved Jini clients and services, called discovering entities, which are required to participate in the multicast discovery protocols. Discovering entities are required to send multicast discovery requests to lookup services with which the entities wish to interact. In addition, they must continuously listen for and act on announcements from the desired lookup services. Interactions with a discovered lookup service may involve registration with that lookup service, or may simply involve querying the lookup service for services of interest (or both). To find specific lookup services, discovering entities also need to be able to participate in the unicast discovery protocol.

Under certain circumstances, a discovering entity may find it useful to allow a third party to perform the entity’s discovery duties. For example, an activatable entity that wishes to deactivate may wish to employ a special Jini technology-enabled service (Jini service)—referred to as a lookup discovery service—to perform discovery duties on its behalf. Such an entity may wish to deactivate for various reasons, one being to conserve computational resources. While the entity is inactive, the lookup discovery service, running on the same or a separate host, would employ the discovery protocols to find lookup services in which the entity has expressed interest and would notify the entity when a previously unavailable lookup service has become available.

The facilities of the lookup discovery service are of particular value in a scenario in which a new lookup service is added to a long-lived djinn containing mul tiple inactive services. Without the use of a lookup discovery service, the time frame over which the new lookup service is fully populated can be both unpredictable and unbounded.

To understand why this time frame can be unpredictable, consider the fact that an inactive service has no way of discovering a new lookup service. This means that each inactive service in the djinn that wishes to discover and join a new lookup service must first activate. Since activation of a service occurs when some client attempts to use the service, the amount of time that passes between the arrival of the new lookup service and the activation of the service can vary greatly over the range of services in the djinn. Thus, the time frame over which the lookup service becomes fully populated cannot be predicted because it could take arbitrarily long before all of the services activate and then discover and join the new lookup service.

In addition to being unpredictable, the time it takes for the lookup service to fully populate can also be unbounded. This is because there is no guarantee that the lookup service will send multicast announcements between the time the service activates and the time it deactivates. If the timing is right, it is possible that one or more of the services in the djinn may never discover and join the new lookup service. Thus, without the use of the lookup discovery service, the new lookup service may never fully populate.

As another example of a discovering entity that may find it useful to allow a third party to perform the entity’s discovery duties, consider an entity that exists in an environment with one of the following characteristics:

• The environment does not support multicast.

• The environment contains no lookup services within the entity’s multicast radius (roughly, the number of hops beyond which neither the multicast requests from the entity nor the multicast announcements from the lookup service will propagate).

• The environment does contain lookup service(s) within the entity’s multicast radius, but at least one service needed by the entity is not registered with any lookup service within that radius.

If such an entity was provided with references to lookup services—located outside of the entity’s multicast radius—that contain services needed by the entity, the entity could contact each lookup service and retrieve the desired service references. One way to provide the entity with access to those lookup services might be to configure the entity to find and use a lookup discovery service, operating beyond the entity’s range, that can employ multicast discovery to find nearby lookup services belonging to groups in which the entity has expressed interest. After acquiring references to the targeted lookup services, the lookup discovery service would pass those references to the entity, providing the entity with access to the services registered with each lookup service. In this way, the entity participates in the multicast discovery protocols through a proxy relationship with the lookup discovery service, gaining access not only to lookup services outside of its own range, but also to all of the services registered with those lookup services. Note that the scenario just described does not come without restrictions. For the lookup discovery service to be able to “link” an entity with lookup services in the way just described, the lookup discovery service must be registered with a lookup service having a location that either is known to the entity or is within the multicast radius of the entity. Furthermore, the lookup discovery service must be running on a host that is located within the multicast radius of the lookup services with which the entity wishes to be linked. That is, the entity must be able to find the lookup discovery service, and the lookup discovery service must be able to find the other desired lookup services.

To address these scenarios, the lookup discovery service participates in both the multicast discovery protocols and the unicast discovery protocol on behalf of a registered discovering entity or client. This service will listen for and process multicast announcement packets from Jini lookup services and will, until successful, repeatedly attempt to discover specific lookup services that the client is interested in finding.

Upon discovery of a previously undiscovered lookup service of interest, the lookup discovery service notifies all entities that have requested the discovery of that lookup service that such an event has occurred. The event mechanism employed by the lookup discovery service satisfies the requirements defined in The Jini Technology Core Platform Specification, “Distributed Events”. Note that the entity that receives such an event notification does not have to be the client of the lookup discovery service; it may be a third-party event-handling service such as an event mailbox service. Once a client is notified of the discovery of a lookup service, it is left to the client to define the semantics of how it interacts with that lookup service. For example, the client may wish to join the lookup service, simply query it for other useful services, or both.

The lookup discovery service must be implemented as a well-behaved Jini service and must comply with all of the policies embodied in the Jini technology programming model. Thus, the resources granted by this service are leased, and implementations of this service must adhere to the distributed leasing model for Jini technology as defined in The Jini Technology Core Platform Specification, “Distributed Leasing”. That is, the lookup discovery service will grant its services for only a limited period of time without an active expression of continuing interest on the part of the client.

LD.1.1. Goals and Requirements

The requirements of the interfaces and classes specified in this document are:

• To define a service that not only employs the Jini discovery protocols to discover, by way of either group association or LookupLocator association, lookup services in which clients have registered interest, but that also notifies its clients of the discovery of those lookup services

• To provide this service in such a way that it can be used by entities that deactivate

• To comply with the policies of the Jini technology programming model

The goals of this document are as follows:

• To describe the lookup discovery service

• To provide guidance in the use and deployment of services that implement the LookupDiscoveryService interface and related classes and interfaces

LD.1.2. Other Types

The types defined in the specification of the LookupDiscoveryService interface are in the net.jini.discovery package. The following object types may be referenced in this chapter. Whenever referenced, these object types will be referenced in unqualified form:

net.jini.core.discovery.LookupLocator 
net.jini.core.event.EventRegistration 
net.jini.core.event.RemoteEventListener 
net.jini.core.lease.Lease 
net.jini.core.lookup.ServiceID 
net.jini.core.lookup.ServiceRegistrar 
net.jini.discovery.DiscoveryEvent 
net.jini.discovery.DiscoveryGroupManagement 
net.jini.discovery.DiscoveryListener 
java.io.IOException 
java.rmi.MarshalledObject 
java.rmi.NoSuchObjectException 
java.rmi.RemoteException 
java.util.Map