Chapter 15: More Complex Examples

This chapter delves into some of the more complex things that can happen with Jini applications.

15.1. Where is the Code?

Clients, servers and service locators can use code from a variety of sources. Which source it uses can depend on the structure of a client and a server. This section looks at some of the variations that can occur.

15.1.1 Problem domain

A service may require information about a client before it can (or will) proceed. For example, a banking service may require a user id and a PIN number. Using the techniques already discussed, this could be done by the client collecting the information and calling suitable methods such as void setName(String name) in the service (or more likely, in the service's proxy) running in the client.


public class Client {
    String getName() {
        ...
	service.setName(...);
	...
    };
}

class Service {
    void setName(String name) {
        ...
    };
}

A service may wish to have more control over the setting of names and passwords than this. For example, it may wish to run verification routines based on the pattern of keystroke entries. More mundanely, it may wish to set time limits on the period between entering the name and the password. Or it may wish to enforce some particular user interface to collect this information. Whatever, the service proxy may wish to perform some sort of input processing on the client side before communicating with the real service. This section explores what happens when the service proxy needs to find extra classes in order to perform this processing.

A standalone application to get a user name might use a GUI interface with the appearance of figure 15.1

Figure 15.1: User interface for name entry
with implementation


package standalone;

import java.awt.*;
import java.awt.event.*;

/**
 * NameEntry.java
 */

public class NameEntry extends Frame {
    
    public NameEntry() {
	super("Name Entry");
	addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {System.exit(0);}
	    });

	Label label = new Label("Name");
	TextField name = new TextField(20);
	add(label, BorderLayout.WEST);
	add(name, BorderLayout.CENTER);
	name.addActionListener(new NameHandler());

	pack();
    }
    
    public static void main(String[] args) {
	
	NameEntry f = new NameEntry();
	f.setVisible(true);
    }
} // NameEntry

class NameHandler implements ActionListener {
    public void actionPerformed(ActionEvent evt) {
	System.out.println("Name was: " + evt.getActionCommand());
    }
}

The classes used in this are
  1. A set of standard classes, Frame, Label, TextField, ActionListener, ActionEvent, BorderLayout, WindowEvent, System.
  2. A couple of new classes NameEntry, NameHandler.
At compile time and at runtime these will need to be accessible.

15.1.2 NameEntry interface

In moving to a Jini system, we have already seen that different components may only need access to a subset of the total set of classes. The same will apply here, but it will critically depend on how the application is changed into a Jini system.

We don't want to be overly concerned about program logic of what is done with the user name once it has been entered, as the interesting part in this section is the location of classes. All versions will need an interface definition, which we can make simply as



package common;

/**
 * NameEntry.java
 */

public interface NameEntry  {
    
    public void show();
    
} // NameEntry

Then the client can call upon an implementation to simply show() itself and collect information in whatever way it chooses. (Note: we don't want to get involved here in the ongoing discussion about the most appropriate interface definition for GUI classes - this is taken up in a later chapter.)

15.1.3 Naive implementation

A simple implementation is



package complex;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

/**
 * NameEntryImpl1.java
 */

public class NameEntryImpl1 extends Frame implements common.NameEntry,
                                          ActionListener, java.io.Serializable {
    
    public NameEntryImpl1() {
	super("Name Entry");
	/*
	addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {System.exit(0);}
	    public void windowOpened(WindowEvent e) {}});
	*/
	setLayout(new BorderLayout());
	Label label = new Label("Name");
	add(label, BorderLayout.WEST);
	TextField name = new TextField(20);
	add(name, BorderLayout.CENTER);
	name.addActionListener(this);

	// don't do this here!
	// pack();
    }

    /**
     * method invoked on pressing <return> in the TextField
     */
    public void actionPerformed(ActionEvent evt) {
	System.out.println("Name was: " + evt.getActionCommand());
    }

    public void show() {
	pack();
	super.show();
    }
    
    
} // NameEntryImpl1

This creates the GUI elements in the constructor. The object is serialisable. That means it will first be created in the server. When sent to the client, its data is serialised. So the entire user interface will be serialized and sent. The instance data isn't too big in this case (about 2,100 bytes), but that is because the example is small. Once it arrives at the client side, a copy will be constructed using this instance data and the class files which will have been pulled down from a server. A GUI with several hundred objects will be much larger. This is overhead, which could be avoided by deferring creation to the client side.

Figure 15.2 shows which instances are running in which JVM.

Figure 15.2: JVM objects for naive implementation

Another problem with this code is that it firstly creates an object on the server machine that has heavy reliance on environmental factors on the server. It then removes itself from that environment and has to re-establish itself on the target client environment. On my current system, this shows by TextField complaining that it cannot find a whole bunch of fonts on my server machine. Well it doesn't matter here: it gets moved to the client machine. (As it happens, the fonts aren't available there either, so I end up with two batches of complaint messages, from the server and from the client. I should only get the client complaints.) It could matter if the service died because of missing stuff on the server side, which would exist on the client.

15.1.4 What files need to be where?

Client
The client needs to know the interface class NameEntry. This must be in its classpath.
Service provider
The server needs to know the class files for
  1. NameEntry
  2. Server1
  3. NameEntryImpl1
These must be in its classpath.
HTTP server
The HTTP server needs to know the class files for
  1. NameEntryImpl1
This must be in the directory of documents for this server.

15.1.5 Factories

The second implementation minimises the amount of serialised code that must be shipped around, by creating as much as possible on the client side. We don't even need to declare the class as a subclass of Frame as that class also exists on the client side. The client calls the interface method show(), and all the GUI creation is moved to there. Essentially, what is created on the server side is a factory object, and this object is moved to the client. The client than makes calls on this factory to create the user interface.



package complex;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

/**
 * NameEntryImpl2.java
 */

public class NameEntryImpl2 implements common.NameEntry,
                                       ActionListener, java.io.Serializable {
    
    public NameEntryImpl2() {
    }

    /**
     * method invoked on pressing <return> in the TextField
     */
    public void actionPerformed(ActionEvent evt) {
	System.out.println("Name was: " + evt.getActionCommand());
    }

    public void show() {
	Frame fr = new Frame("Name Entry");

	fr.addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {System.exit(0);}
	    public void windowOpened(WindowEvent e) {}});

	fr.setLayout(new BorderLayout());
	Label label = new Label("Name");
	fr.add(label, BorderLayout.WEST);
	TextField name = new TextField(20);
	fr.add(name, BorderLayout.CENTER);
	name.addActionListener(this);

	fr.pack();
	fr.show();
    }
    
    
} // NameEntryImpl2

Figure 15.3 shows which instances are running in which JVM.

Figure 15.3: JVM objects for factory implementation

There are some standard classes that cannot be serialised: one example is the Swing JTextArea class (as of Swing 1.1). This has been frequently logged as a bug against Swing. Until this is fixed, the only way one of these objects can be used by a service is to create it on the client.

15.1.6 What files need to be where?

The client needs to know the interface class NameEntry

The server needs to know the class files for

  1. NameEntry
  2. Server2
  3. NameEntryImpl2
  4. NameEntryImpl2$1
The last class in the list is an anonymous class, that acts as the WindowListener. The class file is produced by the compiler. In version 1, this part of the code was commented out for simplicity.

The HTTP server needs to know the class files for

  1. NameEntryImpl2
  2. NameEntryImpl2$1

15.1.7 Implementation three

Apart from the standard classes and a common interface, the previous implementations just used a single class that was uploaded to the lookup service and then passed on to the client. A more realistic situation might require the uploaded service to access a number of other classes that could not be expected to be on the client machine. It is simple to modify the examples to use a server-side specific class for the action listener, instead of the class itself. This looks like



package complex;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

/**
 * NameEntryImpl3.java
 */

public class NameEntryImpl3 implements common.NameEntry,
                                       java.io.Serializable {
    
    public NameEntryImpl3() {
    }

    public void show() {
	Frame fr = new Frame("Name Entry");

	fr.addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {System.exit(0);}
	    public void windowOpened(WindowEvent e) {}});

	fr.setLayout(new BorderLayout());
	Label label = new Label("Name");
	fr.add(label, BorderLayout.WEST);
	TextField name = new TextField(20);
	fr.add(name, BorderLayout.CENTER);
	name.addActionListener(new NameHandler());

	fr.pack();
	fr.show();
    }
    
    
} // NameEntryImpl3

class NameHandler implements ActionListener {
    /**
     * method invoked on pressing <return> in the TextField
     */
    public void actionPerformed(ActionEvent evt) {
	System.out.println("Name was: " + evt.getActionCommand());
    }
} // NameHandler

This version uses a class NameHandler that only exists on the server machine. When the client attempts to deserialise the NameEntryImpl3 instance it will fail to find this class, and be unable to complete deserialisation. How is this resolved? Well, in the same way as before, by making it available through the HTTP server.

Figure 15.4 shows which instances are running in which JVM.

Figure 15.4: JVM objects with multiple classes

15.1.8 What files need to be where?

The client needs to know the interface class NameEntry

The server needs to know the class files for

  1. NameEntry
  2. Server3
  3. NameEntryImpl3
  4. NameEntryImpl3$1
  5. NameHandler
The NameHandler class file is another one produced by the compiler.

The HTTP server needs to know the class files for

  1. NameEntryImpl3
  2. NameEntryImpl3$1
  3. NameHandler

15.2. Running threads from discovery

In all of the simple examples using explicit registration, a single thread was used. That is, as a service locator was discovered, the registration process commenced in the same thread. Now this registration may take some time, and during this time new lookup services may be discovered. To avoid the possibility of these new services timing out and being missed, all registration processing should be carried out in a separate thread, rather than possibly holding up the discovery thread.

15.2.1 Server threads

This section is obsoleted by the JoinManager. I have left it here for the curious.

Running another thread is not a difficult procedure. Basically we have to define a new class that extends Thread and move most of the registration into its run method. This is done in the following version of the ``option 2'' file classifier server, using an inner class


package complex;

import complete.FileClassifierImpl;

import java.rmi.RMISecurityManager;
import net.jini.discovery.LookupDiscovery;
import net.jini.discovery.DiscoveryListener;
import net.jini.discovery.DiscoveryEvent;
import net.jini.core.lookup.ServiceRegistrar;
import net.jini.core.lookup.ServiceItem;
import net.jini.core.lookup.ServiceRegistration;
import net.jini.core.lease.Lease;
// import com.sun.jini.lease.LeaseRenewalManager;
// import com.sun.jini.lease.LeaseListener;
// import com.sun.jini.lease.LeaseRenewalEvent;
import net.jini.lease.LeaseRenewalManager;
import net.jini.lease.LeaseListener;
import net.jini.lease.LeaseRenewalEvent;

/**
 * FileClassifierServer.java
 */

public class FileClassifierServer implements DiscoveryListener, 
                                             LeaseListener {
    
    protected LeaseRenewalManager leaseManager = new LeaseRenewalManager();

    public static void main(String argv[]) {
	new FileClassifierServer();

        // keep server running forever to 
	// - allow time for locator discovery and
	// - keep re-registering the lease
	Object keepAlive = new Object();
	synchronized(keepAlive) {
	    try {
		keepAlive.wait();
	    } catch(InterruptedException e) {
		// do nothing
	    }
	}
    }

    public FileClassifierServer() {

	LookupDiscovery discover = null;
        try {
            discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
        } catch(Exception e) {
            System.err.println(e.toString());
            System.exit(1);
        }

        discover.addDiscoveryListener(this);
    }
    
    public void discovered(DiscoveryEvent evt) {

        ServiceRegistrar[] registrars = evt.getRegistrars();

        for (int n = 0; n < registrars.length; n++) {
            ServiceRegistrar registrar = registrars[n];

	    new RegisterThread(registrar).start();
	}
    }

    public void discarded(DiscoveryEvent evt) {

    }

    public void notify(LeaseRenewalEvent evt) {
	System.out.println("Lease expired " + evt.toString());
    }   

    /**
     * an inner class to register the service in its own thread
     */
    class RegisterThread extends Thread {

	ServiceRegistrar registrar;

	RegisterThread(ServiceRegistrar registrar) {
	    this.registrar = registrar;
	}

	public void run() {
	    ServiceItem item = new ServiceItem(null,
					       new FileClassifierImpl(), 
					       null);
	    ServiceRegistration reg = null;
	    try {
		reg = registrar.register(item, Lease.FOREVER);
	    } catch(java.rmi.RemoteException e) {
		System.err.println("Register exception: " + e.toString());
		return;
	    }
	    System.out.println("service registered");

	    // set lease renewal in place
	    leaseManager.renewUntil(reg.getLease(), Lease.FOREVER, 
				    FileClassifierServer.this);
	}
    }
} // FileClassifierServer

15.2.2 Client threads

It is probably more important to create threads in the client than in the server, since the client will actually perform some computation (which may be lengthy) based on the service it discovers. Again this is a simple matter, moving code into a new class that implements Thread. Doing this to the TestFileClassifier results in



package client;

import common.FileClassifier;
import common.MIMEType;

import java.rmi.RMISecurityManager;
import net.jini.discovery.LookupDiscovery;
import net.jini.discovery.DiscoveryListener;
import net.jini.discovery.DiscoveryEvent;
import net.jini.core.lookup.ServiceRegistrar;
import net.jini.core.lookup.ServiceTemplate;


/**
 * TestFileClassifierThread.java
 */

public class TestFileClassifierThread implements DiscoveryListener {

    public static void main(String argv[]) {
	new TestFileClassifierThread();

        // stay around long enough to receive replies
        try {
            Thread.currentThread().sleep(10000L);
        } catch(java.lang.InterruptedException e) {
            // do nothing
        }
    }

    public TestFileClassifierThread() {
	System.setSecurityManager(new RMISecurityManager());

	LookupDiscovery discover = null;
        try {
            discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
        } catch(Exception e) {
            System.err.println(e.toString());
            System.exit(1);
        }

        discover.addDiscoveryListener(this);

    }
    
    public void discovered(DiscoveryEvent evt) {

        ServiceRegistrar[] registrars = evt.getRegistrars();
 
        for (int n = 0; n < registrars.length; n++) {
	    System.out.println("Service found");
            ServiceRegistrar registrar = registrars[n];

	    new LookupThread(registrar).start();
	}
    }

    public void discarded(DiscoveryEvent evt) {
	// empty
    }

    class LookupThread extends Thread {

	ServiceRegistrar registrar;

	LookupThread(ServiceRegistrar registrar) {
	    this.registrar = registrar;
	}


	public void run() {

	    Class[] classes = new Class[] {FileClassifier.class};
	    FileClassifier classifier = null;
	    ServiceTemplate template = new ServiceTemplate(null, classes, 
							   null);
	    
	    try {
		classifier = (FileClassifier) registrar.lookup(template);
	    } catch(java.rmi.RemoteException e) {
		e.printStackTrace();
		return;
	    }
	    if (classifier == null) {
		System.out.println("Classifier null");
		return;
	    }
	    MIMEType type;
	    try {
		type = classifier.getMIMEType("file1.txt");
		System.out.println("Type is " + type.toString());
	    } catch(java.rmi.RemoteException e) {
		System.err.println(e.toString());
	    }
	}
    }

} // TestFileClassifier


15.3. Inexact Service Matching

Suppose you have a printer service that prints at 30 pages per minute. A client wishes to find a printer that will print at least 24 pages per minute. How will this client find the service? The standard Jini pattern matching will either be for an exact match on an attribute or an ignored match on an attribute. So the only way a client can find this printer is to ignore the speed attribute and perform a later selection among all the printers that it sees.

We can define a printer interface that will allow us to access printer speed (plus other capabilities) as


package common;

import java.io.Serializable;

/**
 * Printer.java
 */

public interface Printer extends Serializable {
    
    public void print(String str);
    public int getSpeed();

} // Printer

Given this, a client can choose a suitably fast printer in a two-step process

  1. Find a service using the lookup exact/ignore match algorithm
  2. Query the service to see if it satifies other types of boolean condition
The following program illustrates how to find a printer that is ``fast enough'':


package client;

import common.Printer;

import java.rmi.RMISecurityManager;

import net.jini.discovery.LookupDiscovery;
import net.jini.discovery.DiscoveryListener;
import net.jini.discovery.DiscoveryEvent;
import net.jini.core.lookup.ServiceRegistrar;
import net.jini.core.lookup.ServiceTemplate;
import net.jini.core.lookup.ServiceMatches;

/**
 * TestPrinterSpeed.java
 */

public class TestPrinterSpeed implements DiscoveryListener {
    
    public TestPrinterSpeed() {

	System.setSecurityManager(new RMISecurityManager());

        LookupDiscovery discover = null;
        try {
            discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
        } catch(Exception e) {
            System.err.println(e.toString());
            System.exit(1);
        }

        discover.addDiscoveryListener(this);

    }
    

    public void discovered(DiscoveryEvent evt) {

        ServiceRegistrar[] registrars = evt.getRegistrars();
        Class[] classes = new Class[] {Printer.class};

        ServiceTemplate template = new ServiceTemplate(null, classes, 
                                                       null);
 
        for (int n = 0; n < registrars.length; n++) {
            ServiceRegistrar registrar = registrars[n];
	    ServiceMatches matches;

	    try {
		matches = registrar.lookup(template, 10);
	    } catch(java.rmi.RemoteException e) {
		e.printStackTrace();
		continue;
	    }
	    // NB: matches.totalMatches may be greater than matches.items.length
	    for (int m = 0; m < matches.items.length; m++) {
		Printer printer = (Printer) matches.items[m].service;

		// Inexact matching is not performed by lookup()
		// we have to do it ourselves on each printer
		// we get
		int speed = printer.getSpeed();
		if (speed >= 24) {
		    // this one is okay, use its print() method
		    printer.print("fast enough printer");
		} else {
		    // we can't use this printer, so just say so
		    System.out.println("Printer too slow at " + speed);
		}
	    }

        }
    }

    public void discarded(DiscoveryEvent evt) {
        // empty
    }

    public static void main(String[] args) {
	
	TestPrinterSpeed f = new TestPrinterSpeed();

        // stay around long enough to receive replies	
        try {
            Thread.currentThread().sleep(10000L);
        } catch(java.lang.InterruptedException e) {
            // do nothing
        }
    }
    
} // TestPrinterSpeed

15.4. Matching using Local Services

When a user connects their laptop into a brand-new network, they will probably know little about the environment they have joined. If they want to use services in this network, they will probably want to use general terms and have them translated into specific terms for this new environment. For example, the user may want to print a file on a nearby printer. In this situation, there is little likelihood that the new user knows how to work out the distance between themselves and the printers. However, a local service could be running which does know how to calculate physical distances between objects on the network.

Finding a ``close enough'' printer then becomes a matter of querying service locators both for printers and for a distance service. As each printer is found, the distance service can be asked to calculate the distance between itself and the laptop (or camera, or any other device that wants to print).

The complexity of the task to be done by clients is growing: a client has to find two sets of services, and when it finds one (a printer) invoke the other (the distance service). This calls for lookup processing to be handled in separate threads. In addition, as each locator is found, it may know about printers, it may know about distance services, both, or none! When the client starts up, it will be discovering these services in arbitrary order, and the code must be structured to deal with this.

Some of the cases that may arise are

  1. A printer may be discovered before any distance service has been found. In this case, the printer must be stored for later distance checking.
  2. A printer may be discovered after a distance service has been found. It can be checked immediately.
  3. A distance service is found, after some printers have been found. This saved set should be checked at this point.
In this problem, we only need to find one distance service, but possibly many printers. The client code given shortly will save printers in a Vector, and a distance service in a single variable.

In searching for printers, we only want to find those that have location information. However, we do not want to match on any particular values. The client will have to use wildcard patterns in a location object. The location information of a printer will need to be retrieved along with the printer, so it can be used. So instead of just storing printers, we need to store ServiceItems, which carry the attribute information as well as the objects.

Of course, for this to work, the client also needs to know where it is! This could be done, for example, by popping up a dialog box asking the user to locate themselves.

A client satisfying these requirements is given in the following program. (The location of the client is hard-coded into the method getMyLocation() for simplicity.)



package client;

import common.Printer;
import common.Distance;

import java.util.Vector;

import java.rmi.RMISecurityManager;
import net.jini.discovery.LookupDiscovery;
import net.jini.discovery.DiscoveryListener;
import net.jini.discovery.DiscoveryEvent;
import net.jini.core.lookup.ServiceRegistrar;
import net.jini.core.lookup.ServiceTemplate;
import net.jini.lookup.entry.Location;
import net.jini.core.lookup.ServiceItem;
import net.jini.core.lookup.ServiceMatches;
import net.jini.core.entry.Entry;

/**
 * TestPrinterDistance.java
 */

public class TestPrinterDistance implements DiscoveryListener {

    protected Distance distance = null;
    protected Object distanceLock = new Object();
    protected Vector printers = new Vector();

    public static void main(String argv[]) {
	new TestPrinterDistance();

        // stay around long enough to receive replies
        try {
            Thread.currentThread().sleep(10000L);
        } catch(java.lang.InterruptedException e) {
            // do nothing
        }
    }

    public TestPrinterDistance() {
	System.setSecurityManager(new RMISecurityManager());

	LookupDiscovery discover = null;
        try {
            discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
        } catch(Exception e) {
            System.err.println(e.toString());
            System.exit(1);
        }

        discover.addDiscoveryListener(this);

    }
    
    public void discovered(DiscoveryEvent evt) {

        ServiceRegistrar[] registrars = evt.getRegistrars();
 
        for (int n = 0; n < registrars.length; n++) {
	    System.out.println("Service found");
            ServiceRegistrar registrar = registrars[n];

	    new LookupThread(registrar).start();
	}
    }

    public void discarded(DiscoveryEvent evt) {
	// empty
    }

    class LookupThread extends Thread {

	ServiceRegistrar registrar;

	LookupThread(ServiceRegistrar registrar) {
	    this.registrar = registrar;
	}


	public void run() {

	    synchronized(distanceLock) {
		// only look for one distance service
		if (distance == null) {
		    lookupDistance();
		}
		if (distance != null) {
		    // found a new distance service
		    // process any previously found printers
		    synchronized(printers) {
			for (int n = 0; n < printers.size(); n++) {
			    ServiceItem item = (ServiceItem) printers.elementAt(n);
			    reportDistance(item);
			}
		    }
		}
	    }

	    ServiceMatches matches = lookupPrinters();
	    for (int n = 0; n < matches.items.length; n++) {
		if (matches.items[n] != null) {
		    synchronized(distanceLock) {
			if (distance != null) {
			    reportDistance(matches.items[n]);
			} else {
			    synchronized(printers) {
				printers.addElement(matches.items[n]);
			    }
			}
		    }
		}
	    }
	}

	/*
	 * We must be protected by the lock on distanceLock here
	 */
	void lookupDistance() {
	    // If we don't have a distance service, see if this
	    // locator knows of one
	    Class[] classes = new Class[] {Distance.class};
	    ServiceTemplate template = new ServiceTemplate(null, classes, 
							   null);
	    
	    try {
		distance = (Distance) registrar.lookup(template);
	    } catch(java.rmi.RemoteException e) {
		e.printStackTrace();
	    }

	}

	ServiceMatches lookupPrinters() {
	    // look for printers with
	    // wildcard matching on all fields of Location
	    Entry[] entries = new Entry[] {new Location(null, null, null)};

	    Class[] classes = new Class[1];
	    try {
		classes[0] = Class.forName("common.Printer");
	    } catch(ClassNotFoundException e) {
		System.err.println("Class not found");
		System.exit(1);
	    }
	    ServiceTemplate template = new ServiceTemplate(null, classes, 
							   entries);
	    ServiceMatches matches = null;
	    try {
		matches =  registrar.lookup(template, 10);
	    } catch(java.rmi.RemoteException e) {
		e.printStackTrace();
	    }
	    return matches;
	}

	/**
	 * report on the distance of the printer from
	 * this client
	 */
	void reportDistance(ServiceItem item) {
	    Location whereAmI = getMyLocation();
	    Location whereIsPrinter = getPrinterLocation(item);
	    if (whereIsPrinter != null) {
		int dist = distance.getDistance(whereAmI, whereIsPrinter);
		System.out.println("Found a printer at " + dist +
				   " units of length away");
	    }
	}

	Location getMyLocation() {
	    return new Location("1", "1", "Building 1");
	}

	Location getPrinterLocation(ServiceItem item) {
	    Entry[] entries = item.attributeSets;
	    for (int n = 0; n < entries.length; n++) {
		if (entries[n] instanceof Location) {
		    return (Location) entries[n];
		}
	    }
	    return null;
	}
    }

} // TestFileClassifier


A number of services will need to be running. At least one distance service will be needed, implementing the interface Distance


package common;

import net.jini.lookup.entry.Location;

/**
 * Distance.java
 */

public interface Distance extends java.io.Serializable {
    
    int getDistance(Location loc1, Location loc2);

} // Distance

An example implementation is

package complex;

import net.jini.lookup.entry.Location;

/**
 * DistanceImpl.java
 */

public class DistanceImpl implements common.Distance {
    
    public DistanceImpl() {
	
    }

    /**
     * A very naive distance metric
     */
    public int getDistance(Location loc1, Location loc2) {
	int room1, room2;
	try {
	    room1 = Integer.parseInt(loc1.room);
	    room2 = Integer.parseInt(loc2.room);
	} catch(Exception e) {
	    return -1;
	}
	int value = room1 - room2;
	return (value > 0 ? value : -value);
    }
    
} // DistanceImpl

We have already covered some printers, we can just reuse them. A simple program to start up a distance service and two printers is

package complex;

import printer.Printer30;
import printer.Printer20;
import complex.DistanceImpl;

// import com.sun.jini.lookup.JoinManager;
import net.jini.lookup.JoinManager;
import net.jini.core.lookup.ServiceID;
// import com.sun.jini.lookup.ServiceIDListener;
// import com.sun.jini.lease.LeaseRenewalManager;
import net.jini.lookup.ServiceIDListener;
import net.jini.lease.LeaseRenewalManager;
import net.jini.discovery.LookupDiscovery;
import net.jini.lookup.entry.Location;
import net.jini.core.entry.Entry;
import net.jini.discovery.LookupDiscoveryManager;

/**
 * PrinterServerLocation.java
 */

public class PrinterServerLocation implements ServiceIDListener {
    
    public static void main(String argv[]) {
	new PrinterServerLocation();

        // run forever
	Object keepAlive = new Object();
	synchronized(keepAlive) {
	    try {
		keepAlive.wait();
	    } catch(InterruptedException e) {
		// do nothing
	    }
	}    
    }

    public PrinterServerLocation() {

	JoinManager joinMgr = null;
	try {
	    LookupDiscoveryManager mgr = 
		new LookupDiscoveryManager(LookupDiscovery.ALL_GROUPS,
					   null /* unicast locators */,
					   null /* DiscoveryListener */);
	    // distance service
	    joinMgr = new JoinManager(new DistanceImpl(),
				      null,
				      this,
				      mgr,
				      new LeaseRenewalManager());


	    // slow printer in room 20
	    joinMgr = new JoinManager(new Printer20(),
				      new Entry[] {new Location("1", "20", 
								"Building 1")},
				      this,
				      mgr,
				      new LeaseRenewalManager());

	    // fast printer in room 30
	    joinMgr = new JoinManager(new Printer30(),
				      new Entry[] {new Location("1", "30", 
								"Building 1")},
				      this,
				      mgr,
				      new LeaseRenewalManager());


	} catch(Exception e) {
	    e.printStackTrace();
	    System.exit(1);
	}
    }

    public void serviceIDNotify(ServiceID serviceID) {
	System.out.println("got service ID " + serviceID.toString());
    }
    
} // PrinterServerLocation

15.5. Finding a Service Once Only

This section is obsoleted by the ServiceDiscoveryManager. I have left it here for the curious.

There may be many lookup services on the local network, perhaps specialising in certain groups of services. There could be many lookup services running on the Internet, which could act as global repositories of information. One may expect to find lookup services acting in a "portal" role, such as listing all of the public clock services, the real estate services, and so on.

A service will probably register with as many service locators as it can, to improve its chances of being found. On the other hand, clients looking for a service may be content to find just a single suitable implementation, or may wish to find all service implementations. This second case can cause some uniqueness problems: if a client finds every service which has been registered with multiple locators, then it will probably find the same service more than once!

Why is this an issue? Well, suppose the client wants to find all power drills in the factory, and ask them to drill exactly one hole. Or suppose it finds all backup services for the system, and wants each one to perform a single backup. Then it needs to know the identity of each service, so that it can tell when it is getting a duplicate copy from another locator source. Otherwise, it might get each drill to make six holes as it gets a copy from six service locators, or might perform six backups of the same data. Whenever a service can perform a non-idempotent service (i.e. one in which repeating the action has a different effect each time), then duplicate copies on the client side must be avoided.

Jini has a concept of a service being a ``good citizen''. This concept includes having a single identity across all lookup services. This allows clients to tell whether they have come across multiple copies of the same service, or have encountered another different implementation of the service. The behaviour on the part of services is contained in the Jini ``Lookup Service'' specification, and hinges on the use of the ServiceID.

A ServiceID can be specified when registering a service with a service locator. If this is the first time this service has ever been registered, then this should be null. The service locator will then generate a non-null ServiceID that can be used in future to identify this service. This object is specified to be unique, so that a service locator cannot generate the same one for two different services and two different locators cannot generate the same one. This provides a unique identifier that can be used to identify duplicates.

The procedure to follow is

  1. The very, very first time a service is registered, use null as the serviceID value of the ServiceItem used in ServiceRegistrar.register().
  2. The returned ServiceRegistration has a method getServiceID() to give the ServiceID. This should then be used in any future registrations both with this service locator and with any other one. This is to ensure that the service has a unique identity across all lookup services. It should be noted that JoinManager already does this, although this is not stated in its documentation. We have done this too in examples.
  3. The client has a choice of two lookup() methods to use with its ServiceRegistrar object: the first just returns a single object, the second returns an array of ServiceMatches objects. This second one is more useful here, as it can give the array of ServiceItem objects, and the ServiceID can be extracted from there.
  4. The client should maintain a list of service id's that it has seen, and compare any new ones against it - then it can check if a service is a new one, or a previously seen one.
  5. The service should save its id in persistent storage so that if it dies and restarts, then it can use the same id - after all, it is the same service. (This may be subtle: it should only do this if it really is the same service. For example, if the service maintains state which is lost in a crash, then it isn't the same service!)
A modified client doing this is:


package unique;

import common.FileClassifier;
import common.MIMEType;

import java.rmi.RMISecurityManager;
import net.jini.discovery.LookupDiscovery;
import net.jini.discovery.DiscoveryListener;
import net.jini.discovery.DiscoveryEvent;
import net.jini.core.lookup.ServiceRegistrar;
import net.jini.core.lookup.ServiceTemplate;
import net.jini.core.lookup.ServiceMatches;
import net.jini.core.lookup.ServiceItem;
import net.jini.core.lookup.ServiceID;

import java.util.Vector;

/**
 * TestFileClassifier.java
 */

public class TestFileClassifier implements DiscoveryListener {

    protected Vector serviceIDs = new Vector();

    public static void main(String argv[]) {
	new TestFileClassifier();

        // stay around long enough to receive replies
        try {
            Thread.currentThread().sleep(10000L);
        } catch(java.lang.InterruptedException e) {
            // do nothing
        }
    }

    public TestFileClassifier() {
	System.setSecurityManager(new RMISecurityManager());

	LookupDiscovery discover = null;
        try {
            discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
        } catch(Exception e) {
            System.err.println(e.toString());
            System.exit(1);
        }

        discover.addDiscoveryListener(this);

    }
    
    public void discovered(DiscoveryEvent evt) {

        ServiceRegistrar[] registrars = evt.getRegistrars();
	Class [] classes = new Class[] {FileClassifier.class};
	FileClassifier classifier = null;
	ServiceTemplate template = new ServiceTemplate(null, classes, 
						       null);
 
        for (int n = 0; n < registrars.length; n++) {
	    System.out.println("Service found");
            ServiceRegistrar registrar = registrars[n];
	    ServiceMatches matches = null;
	    try {
		 matches = registrar.lookup(template, 10);
	    } catch(java.rmi.RemoteException e) {
		e.printStackTrace();
		continue;
	    }

	    ServiceItem[] items = matches.items;
	    for (int m = 0; m < items.length; m++) {
		ServiceID id = items[m].serviceID;
		if (serviceIDs.indexOf(id) != -1) {
		    // found a new serviceID - record it and use it
		    classifier = (FileClassifier) items[m].service;
		    if (classifier == null) {
			System.out.println("Classifier null");
			continue;
		    }

		    serviceIDs.add(id);

		    MIMEType type;
		    try {
			type = classifier.getMIMEType("file1.txt");
			System.out.println("Type is " + type.toString());
		    } catch(java.rmi.RemoteException e) {
			System.err.println(e.toString());
		    }
		}
	    }
	}
    }

    public void discarded(DiscoveryEvent evt) {
	// empty
    }
} // TestFileClassifier

15.6. Leased Changes to a Service

This section still uses the old Jini 1.2 classes. It is not correct for Jini 2.0. The example in this section is out of date and will not compile or run. It will be brought up to date soon.

Sometimes a service may allow changes to its state to be made by external (remote) objects. This happens all the time to service locators, which have services added and removed. A service may wish to behave in the same manner as the locators, and just grant a lease for the change. After the lease has expired, the service will remove the change. Such a situation may occur with file classification, where a new service starts that can handle a particular MIME type: it can register the filename mapping with a file classifier service. However, the file classifier service will just timeout the mapping unless the new service keeps it renewed.

The example of this section follows the lease management section of the chapter on ``Leases''. It gives a concrete illustration of that section now that there is enough background to do so.

15.6.1 Leased FileClassifier

A dynamically extensible version of a file classification will have methods to add and remove MIME mappings:



package common;

import java.io.Serializable;

/**
 * LeaseFileClassifier.java
 */

import net.jini.core.lease.Lease;

public interface LeaseFileClassifier extends Serializable {

    public MIMEType getMIMEType(String fileName) 
	throws java.rmi.RemoteException;
    
    /*
     * Add the MIME type for the given suffix.
     * The suffix does not contain '.' e.g. "gif".
     * @exception net.jini.core.lease.LeaseDeniedException
     * a previous MIME type for that suffix exists.
     * This type is removed on expiration or cancellation
     * of the lease.
     */
    public Lease addType(String suffix, MIMEType type)
	throws java.rmi.RemoteException,  
	       net.jini.core.lease.LeaseDeniedException;

    /**
     * Remove the MIME type for the suffix.
     * This shouldn't be public, but I haven't
     * figured out the best way of handling a
     * "rollback" method yet. Jini Transactions?
     */
    public void removeType(String suffix)
	throws java.rmi.RemoteException;
} // LeaseFileClasssifier




The addType() method returns a lease. We shall use the landlord leasing system discussed in an earlier chapter. The client and the service will be in different Java VM's, probably on different machines. Figure 15.5 gives the object structure on the service side.

Figure 15.5: Class diagram for leasing on the server

On the client side, the lease object will be a copy of the lease created on the server (normally RMI semantics), but the other objects from the service will be stubs that call into the real objects on the service. This is shown in figure 15.6.

Figure 15.6: Class diagram for leasing on the client

15.6.2 FileClassifier Leased Resource

The FileClassifierLeasedResource acts as a wrapper around the actual resource. It adds cookie and time expiration fields around the resource. It adds a unique cookie mechanism, in addition to making the wrapped resource visible.


/**
 * FileClassifierLeasedResource.java
 */
package lease;

import common.LeaseFileClassifier;
import com.sun.jini.lease.landlord.LeasedResource;

public class FileClassifierLeasedResource implements LeasedResource  {
    
    static protected int cookie = 0;
    protected int thisCookie;
    protected LeaseFileClassifier fileClassifier;
    protected long expiration = 0;
    protected String suffix = null;

    public FileClassifierLeasedResource(LeaseFileClassifier fileClassifier,
					String suffix) {
        this.fileClassifier = fileClassifier;
	this.suffix = suffix;
	thisCookie = cookie++;
    }

    public void setExpiration(long newExpiration) {
	this.expiration = newExpiration;
    }

    public long getExpiration() {
	return expiration;
    }
    public Object getCookie() {
	return new Integer(thisCookie);
    }

    public LeaseFileClassifier getFileClassifier() {
	return fileClassifier;
    }

    public String getSuffix() {
	return suffix;
    } 
} // FileClassifierLeasedResource

15.6.3 FileClassifier Lease Manager

The FileClassifierLeaseManager is very similar to the code give for the FooLeaseManager in the chapter on Leases.



/**
 * FileClassifierLeaseManager.java
 */
package lease;

import java.util.*;
import common.LeaseFileClassifier;

import net.jini.core.lease.Lease;
import com.sun.jini.lease.landlord.LeaseManager;
import com.sun.jini.lease.landlord.LeasedResource;
import com.sun.jini.lease.landlord.LeaseDurationPolicy;
import com.sun.jini.lease.landlord.Landlord;
import com.sun.jini.lease.landlord.LandlordLease;
import com.sun.jini.lease.landlord.LeasePolicy;
import java.util.Map;

public class FileClassifierLeaseManager implements LeaseManager {

    protected static long DEFAULT_TIME = 30*1000L;

    protected Vector fileClassifierResources = new Vector();
    protected LeaseDurationPolicy policy;

    public FileClassifierLeaseManager(Landlord landlord) {
	policy = new LeaseDurationPolicy(Lease.FOREVER,
					 DEFAULT_TIME,
					 landlord,
					 this,
					 new LandlordLease.Factory());
	new LeaseReaper().start();
    }
    
    public void register(LeasedResource r, long duration) {
        fileClassifierResources.add(r);
    }

    public void renewed(LeasedResource r, long duration, long olddur) {
	// no smarts in the scheduling, so do nothing
    }

    public Map cancelAll(Object[] cookies) {
        for (int n = cookies.length; --n >= 0; ) {
            cancel(cookies[n]);
        }
	return null;
    }

    public void cancel(Object cookie) {
	for (int n = fileClassifierResources.size(); --n >= 0; ) {
	    FileClassifierLeasedResource r = (FileClassifierLeasedResource) fileClassifierResources.elementAt(n);
	    if (!policy.ensureCurrent(r)) {
		System.out.println("Lease expired for cookie = " + 
				   r.getCookie());
		try {
		    r.getFileClassifier().removeType(r.getSuffix());
		} catch(java.rmi.RemoteException e) {
		    e.printStackTrace();
		}
		fileClassifierResources.removeElementAt(n);
	    }
	}
    }

    public LeasePolicy getPolicy() {
	return policy;
    }

    public LeasedResource getResource(Object cookie) {
	for (int n = fileClassifierResources.size(); --n >= 0; ) {
	    FileClassifierLeasedResource r = (FileClassifierLeasedResource) fileClassifierResources.elementAt(n);
	    if (r.getCookie().equals(cookie)) {
		return r;
	    }
	}
	return null;
    }

    class LeaseReaper extends Thread {
        public void run() {
            while (true) {
                try {
                    Thread.sleep(DEFAULT_TIME) ;
                }
                catch (InterruptedException e) {
		}
                for (int n = fileClassifierResources.size()-1; n >= 0; n--) {
                    FileClassifierLeasedResource r = (FileClassifierLeasedResource) 
			                   fileClassifierResources.elementAt(n)
 ;
                    if (!policy.ensureCurrent(r)) {
                        System.out.println("Lease expired for cookie = " + 
					   r.getCookie()) ;
			try {
			    r.getFileClassifier().removeType(r.getSuffix());
			} catch(java.rmi.RemoteException e) {
			    e.printStackTrace();
			}
			fileClassifierResources.removeElementAt(n);
			
                    }
                }
            }
        }
    }

} // FileClassifierLeaseManager

15.6.4 FileClassifier Landlord

The FileClassifierLandlord is very similar to the FooLandlord in the chapter on Leases.



/**
 * FileClassifierLandlord.java
 */

package lease;

import common.LeaseFileClassifier;

import com.sun.jini.lease.landlord.*;
import net.jini.core.lease.LeaseDeniedException;
import net.jini.core.lease.Lease; 
import java.rmi.server.UnicastRemoteObject;
import java.rmi.Remote;
import java.util.Map;

public class FileClassifierLandlord extends UnicastRemoteObject implements Landlord, Remote {

    FileClassifierLeaseManager manager = null;

    public FileClassifierLandlord() throws java.rmi.RemoteException {
	manager = new FileClassifierLeaseManager(this);
    }
    
    public void cancel(Object cookie) {
	manager.cancel(cookie);
    }

    public Map cancelAll(Object[] cookies) {
	return manager.cancelAll(cookies);
    }

    public long renew(java.lang.Object cookie,
		      long extension) 
	throws net.jini.core.lease.LeaseDeniedException,
	       net.jini.core.lease.UnknownLeaseException {
	LeasedResource resource = manager.getResource(cookie);
	if (resource != null) {
	    return manager.getPolicy().renew(resource, extension);
	}
	return -1;
    }

    public Lease newFileClassifierLease(LeaseFileClassifier fileClassifier, 
					String suffixKey, long duration) 
	throws LeaseDeniedException {
	FileClassifierLeasedResource r = new FileClassifierLeasedResource(fileClassifier,
									  suffixKey);
	return manager.getPolicy().leaseFor(r, duration);
    }

    public Landlord.RenewResults renewAll(java.lang.Object[] cookie,
					  long[] extension) {
	return null;
    }
} // FileClassifierLandlord

15.7. Copyright

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 . The current edition of the book does not yet deal with Jini 2.0, but the next edition will.

This file is Copyright (©) 1999, 2000, 2001, 2003, 2004 by Jan Newmarch (http://jan.netcomp.edu.au) jan@newmarch.name.

Creative Commons License This work is licensed under a Creative Commons License, the replacement for the earlier Open Content License.