28.

  

ServiceRegistrar

The ServiceRegistrar is an abstract class that is implemented by each lookup service. The actual details of this implementation are not relevant here. The role of a ServiceRegistrar is to act as a proxy for the lookup service. This proxy runs in the application, which may be a service or a client.

This is the first object that is moved from one JVM to another by Jini. It is shipped from the lookup service to the application looking for the lookup service, using a socket connection. From then on, it runs as an object in the application's address space, and the application makes normal method calls to it. When needed, it communicates back to its lookup service. The implementation used by Sun's reggie uses RMI to communicate, but the application does not need to know this, and anyway, it could be done in different ways. This proxy object should not cache any information on the application side, but instead should get "live" information from the lookup service as needed. The implementation of the lookup service supplied by Sun does exactly this.

The ServiceRegistrar object has two major methods . One is used by a service attempting to register:

 public ServiceRegistration register(ServiceItem item,                                     long leaseDuration)                              throws java.rmi.RemoteException 

The other method (with two forms) is used by a client trying to locate a particular service:

 public java.lang.Object lookup(ServiceTemplate tmpl)                         throws java.rmi.RemoteException; public ServiceMatches lookup(ServiceTemplate tmpl,                              int maxMatches)                       throws java.rmi.RemoteException; 

The details of these methods are given in Chapter 6. For now, an overview will suffice.

A service provider will register a service object (that is, an instance of a class), and a set of attributes for that object. For example, a printer may specify that it can handle Postscript documents, or a toaster that it can deal with frozen slices of bread. The service provider may register a singleton object that completely implements the service, but more likely it will register a service proxy that will communicate back to other objects in the service provider. Note carefully : the registered object will be shipped around the network, and when it finally gets to run, it may be a long way away from where it was originally created. It will have been created in the service's JVM, transferred to the lookup locator by register() , and then to the client's JVM by lookup() .

A client is trying to find a service using some properties of the service that it knows about. Whereas the service can export a live object, the client cannot use a service object as a property, because then it would already have the thing, and wouldn't need to try to find one! What it can do is use a class object, and try to find instances of this class lying around in service locators. As discussed later in Chapter 6, it is best if the client asks for an interface class object. In addition to this class specification, the client may specify a set of attribute values that it requires from the service.

The next step is to look at the possible forms of attribute values, and at how matching will be performed. This is done using Jini Entry objects, which are discussed in Chapter 4 later.

Information from the ServiceRegistrar

The ServiceRegistrar is returned after a successful discovery has been made. This object has a number of methods that will return useful information about the lookup service. So, in addition to using this object to register a service or to look up a service, you can use it to find out about the lookup locator. The major methods are these:

 String[] getGroups();; LookupLocator getLocator(); ServiceID getServiceID(); 

The first method, getGroups() , will return a list of the groups that the locator is a member of.

The second method, getLocator() , is more interesting. This returns exactly the same type of object as is used in the unicast lookup, but now its fields are filled in by the discovery process. You can find out which host the locator is running on, and its hostname, by using the following statement:

 registrar.getLocator().getHost(); 

The following code shows how this can be used in the discovered () method to print information about each lookup service that replies to the multicast request:

 public void discovered(DiscoveryEvent evt) {     ServiceRegistrar[] registrars = evt.getRegistrars();     for (int n = 0; n < registrars.length; n++) {          ServiceRegistrar registrar = registrars[n];          System.out.println("Service locator at " +                             registrar.getLocator().getHost());     } } 

You could use the discovered() method to find out where a service locator is so that the next time this program runs, it could connect directly by unicast.

The third method, getServiceID() , is unlikely to be of much use to you. In general, service IDs are used to give a globally unique identifier for the service (different services should not have the same ID), and a service should have the same ID with all service locators. However, this is the service ID of the lookup service, not of any services registered with it.