15.

  

LookupDiscoveryService

It is easy enough for a server to discover all of the lookup services within reach at the time it is started, by using LookupDiscovery . While the server continues to stay alive , any new lookup services that start will also be found by LookupDiscovery . But if the server terminates, which it will for activable services, then any new lookup services will probably never be found. This will result in the service not being registered with them, which could mean that clients may not find it. This is analogous to leases not being renewed if the server terminates.

Jini 1.1 supplies a service, the LookupDiscoveryService , that can be used to continuously monitor the state of lookup services. It will monitor them on behalf of a service that will most likely want to register with each new lookup service as it starts. If the service is an activatable one, the server that would have done registered the service will have terminated , as its role would have just been to register the service with rmid .

When there is a change to lookup services, the LookupDiscoveryService needs to notify an object about this by sending it a remote event (actually of type Remote-DiscoveryEvent ). But again, we do not want to have a process sitting around waiting for such notification, so the listener object will probably also be an activatable object.

The LookupDiscoveryService interface has the following specification:

 package net.jini.discovery; public interface LookupDiscoveryService {     LookupDiscoveryRegistration register(String[] groups,                                          LookupLocator[] locators,                                          RemoteEventListener listener,                                          MarshalledObject handback,                                          long leaseDuration); } 

Calling the register() method will begin a multicast search for the groups and unicast lookup for the locators . The registration is leased and will need to be renewed before expiring (a lease renewal service can be used for this). Note that the listener cannot be null -this is simple sanity checking, for if the listener was null , then the service could never do anything useful.

A lookup service in one of the groups can start or terminate, or it can change its group membership in such a way that it now does (or doesn't) meet the group criteria. A lookup service in the locators list can also start or stop. These will generate RemoteDiscoveryEvent events and call the notify() method of the listener. The event interface includes the following:

 package net.jini.discovery; public interface RemoteDiscoveryEvent {     ServiceRegistrar[] getRegistrars();     boolean isDiscarded();     ... } 

The list of registrars is the set that triggered the event. The isDiscarded() method is used to check whether the lookup service is a " discovered " lookup service or a "discarded" lookup service. An initial event is not posted when the listener is registered: the set of lookup services that are initially found can be retrieved from the LookupDiscoveryRegistration object returned from the register() method by its getRegistrars() .

The Fiddler Service

The Jini 1.1 release includes an implementation of the lookup discovery service called fiddler . It is a non-lazy activatable service and is started much like other services, such as reggie:

 java -jar [setup_jvm_options] executable_jar_file      codebase_arg fiddler_policy_file_arg      log_directory_arg [groups and locators]      [server_jvm] [server_jvm_args] 

For example,

 java -jar \         -Djava.security.policy=/files/jini1_1/example/txn/policy.all \         /files/jini1_1/lib/fiddler.jar \         http://`hostname`:8080/norm-dl.jar \         /files/jini1_1/example/books/policy.all /tmp/fiddler_log