Chapter 5: Service Registration

This chapter looks at how services register themelves with lookup locators so that they can later be found by clients.

A server for a service finds a service locator using unicast lookup with a LookupLocator or multicast search using LookupDiscovery. In both cases, a ServiceRegistrar object is returned to act as a proxy for the lookup service. The server then registers the service with the service locator using the ServiceRegistrar method register():

package net.jini.core.lookup;

public Class ServiceRegistrar {
    public ServiceRegistration register(ServiceItem item,
                                       long leaseDuration)
                               throws java.rmi.RemoteException;
}

package net.jini.core.lookup;

public Class ServiceItem {
    public ServiceID serviceID;
    public java.lang.Object service;
    public Entry[] attributeSets;

    public ServiceItem(ServiceID serviceID,
                   java.lang.Object service,
                   Entry[] attrSets);
}

The service provider will create a ServiceItem object, using the constructor and pass it into register(). The serviceID is set to null when the service is registered for the first time. The lookup service will set a non-null value as it registers the service. On subsequent registrations or re-registrations, this non-null value should be used. The serviceID is used as a globally unique identifier for the service.

The second parameter is the service object that is being registered. This object will be serialised and sent to the service locator for storage. When a client later requests a service, this is the object it will be given. There are several things to note about the service object:

• The object must be serialisable. Some objects, such as Swing's JTextArea are not serialisable at present and so cannot be used.
• The object is created in the service's JVM. However, when it runs it will do so in the client's JVM. It may need to be a proxy for the actual service. For example, it may be able to show a set of toaster controls, but will have to send messages across the network to the real toaster service, which is connected to the physical toaster.
• If the service object is an RMI proxy, then the object in the ServiceItem is given by the programmer as the UnicastRemoteObject for the proxy stub, not the proxy itself. The Java runtime substitutes the proxy. This subtlety is explored in a later chapter.

The third parameter is a set of entries giving information about the service in addition to the service object/service proxy itself. If there is no additional information, this can be null.

The service attempts to register itself by calling register(). This may throw an java.rmi.RemoteException which must be caught. The second parameter is a request to the service locator for the length of time to store the service. The time requested may or may not be honoured. The return value is of type ServiceRegistration

This registration object is created by the lookup service and is returned to run in the service provider. The registration acts as a proxy object to control the state maintained about the exported service object stored on the lookup service. Actually, this can be used to make changes to the entire ServiceItem stored on the lookup service. The registration maintains a field serviceID which is used to identify the ServiceItem on the lookup service. This can be retrieved by getServiceID() for reuse by the server if it needs to do so (which it should). These objects are shown in figure 5.1.

Other methods such as

 
void addAttributes(Entry[] attrSets);
void modifyAttributes(Entry[] attrSetTemplates, Entry[] attrSets);
void setAttributes(Entry[] attrSets);

The final public method for this class is getLease() which returns a Lease object, which allows renewal or cancellation of the lease. This is discussed in more detail in Leases

The major task of the server is then over. It will have successfully exported the service to a number of lookup services. What the server then does depends on how long it needs to keep the service alive or registered. If the exported service can do everything that the service needs to do, and does not need to maintain long-term registration, then the server can simply exit. More commonly, if the exported service object acts as a proxy and needs to communicate back to the service then the server can sleep so that it maintains existence of the service. If the service needs to be re-registered before timeout occurs then the server can also sleep in this situation.

A unicast server that exports its service and does nothing else is in the following program:

package basic;

import net.jini.core.discovery.LookupLocator;
import net.jini.core.lookup.ServiceRegistrar;
import net.jini.core.lookup.ServiceItem;
import net.jini.core.lookup.ServiceRegistration;
import java.io.Serializable;

/**
 * SimpleService.java
 */

public class SimpleService implements Serializable {
    
    static public void main(String argv[]) {
        new SimpleService();
    }
   
    public SimpleService() {
	LookupLocator lookup = null;
	ServiceRegistrar registrar = null;

        try {
            lookup = new LookupLocator("jini://localhost");
        } catch(java.net.MalformedURLException e) {
            System.err.println("Lookup failed: " + e.toString());
	    System.exit(1);
        }

	try {
	    registrar = lookup.getRegistrar();
	} catch (java.io.IOException e) {
            System.err.println("Registrar search failed: " + e.toString());
	    System.exit(1);
	} catch (java.lang.ClassNotFoundException e) {
            System.err.println("Registrar search failed: " + e.toString());
	    System.exit(1);
	}

	// register ourselves as service, with no serviceID
	// or set of attributes
	ServiceItem item = new ServiceItem(null, this, null);
	ServiceRegistration reg = null;
	try {
	    // ask to register for 10,000,000 milliseconds
	    reg = registrar.register(item, 10000000L);
	} catch(java.rmi.RemoteException e) {
	    System.err.println("Register exception: " + e.toString());
	}
	System.out.println("Service registered");

	// we can exit here if the exported service object can do
	// everything, or we can sleep if it needs to communicate 
	// to us or we need to renew a lease later
	//
	// Typically, we will need to renew a lease later 
    }
   
} // SimpleService

The program needs to be compiled and run with jini-core.jar in its CLASSPATH. When run, it will attempt to connect to the service locator, so obviously one needs to be running on the machine specified in order for this to happen. Otherwise, it will throw an exception and terminate.

The instance data for the service object is transferred in serialized form across socket connections. This instance data is kept in this serialized form by the lookup services. Later, when a client asks for the service to be reconstituted, it will use this instance data and also will need the class files. At this point, the class files will also need to be transferred, probably by an HTTP server. There is no need for additional RMI support services such as rmiregistry or rmid since all registration is done by the method register().

ServiceID getServiceID();
Lease getLease();

long duration = reg.getLease().getExpiration() -
                System.currentTimeMillis();
System.out.println("Lease expires at: " +
                   duration +
                   " milliseconds from now");

A service is unique in the world. It runs on a particular machine and performs certain tasks. However, it will probably register itself with many lookup services. It should have the same ``identity'' on all of these. In addition if either the service or one of these locators crashes or restarts, then this identity should be the same as before.

The ServiceID plays the role of unique identifier for a service. It is a 128-bit number generated in a pseudo-random manner, and is effectively unique: the chance that the generator might duplicate this number is vanishingly small. Services do not generate this identifier, as the actual algorithm is not a public method of any class. Instead, a lookup service should be used. When a service needs a new identifier, it should register with a lookup service using a null service id. The lookup service will then return a value.

The first time a service starts, it should ask for a service id from the first lookup service it registers with. It should reuse this for registration with every other lookup service from then on. If it crashes and restarts, then it should use the same service id again, which implies it should save it in persistent storage and retrieve it on restarting. The code above is not well-behaved in this respect.

A service can announce a number of entry attributes when it registers itself with a lookup service. It does so by preparing an array of Entry objects and passing them into the ServiceItem used in the register() method of the registrar. The service can include as much as it wants to in this: in later searches by clients each entry is treated as though it was or'ed with the other entries. In other words, the more entries that are given by the service, the greater the chance of matching a client's requirements.

For example, we have a coffee machine on the 7th level of our building, which is known as both ``GP South Building'' and ``General Purpose South Building''. Information such as this, and general stuff about the coffee machine can be encapsulated in the convenience classes Location and Comment from the net.jini.lookup.entry package. If this was on our network as a service, it would advertise itself as

import net.jini.lookup.entry.Location;
import net.jini.lookup.entry.Comment;

Location loc1 = new Location("7", "728", 
                             "GP South Building");
Location loc2 = new Location("7", "728", 
                             "General Purpose South Building");
Comment comment = new Comment("DSTC coffee machine");

Entry[] entries = new Entry[] {loc1, loc2, comment};

ServiceItem item = new ServiceItem(..., ..., entries);
registrar.register(item, ...);

A service uses the ServiceRegistrar object returned as a proxy from a locator to register itself with that locator. The service prepares a ServiceItem that contains a service object and a set of entries. The service object may be a proxy for the real service. It registers this using the register method of the ServiceRegistrar object.

Information about a registration is returned as a ServiceRegistration object. This may be queried for information such as the lease and its duration.

If you found this chapter of value, the full book is available from APress or Amazon . There is a review of the book at Java Zone