126.

  

Entry Class

When a service provider registers a service, it places a copy of the service object (or a service proxy) on the lookup service. This copy is an instance of a class, albeit in serialized form. The server can optionally register sets of attributes along with the service object. Each set is described by an Entry object. What is stored on each service locator is an instance of a class along with a set of Entry objects, each of which describes some special additional attributes of the service.

For example, a set of file editors may be available as services. Each editor is capable of editing different types of files, as shown in Figure 4-1.

Figure 4-1: Editor class diagram

Note  

These classes would probably be interfaces, rather than instantiable classes .

In this situation, a client could search for a suitable editor in two ways:

• By asking for an instance of a specific class, such as ImageEditor
• By asking for an instance of the general class Editor with the additional information that it can handle a certain type of file

The type of search performed depends on the problem domain, as defined by the services and possible clients . Services advertise themselves by exporting an object that is of a particular class and by exporting additional information along with this object. Jini clients can then search for specific types of services by asking for an object that implements the specific class, such as ImageEditor . They can also search for superclass objects and include extra objects to narrow the search, based on additional information advertised by the service. This additional information is given in objects belonging to subclasses of the Entry class.

The Entry class allows services to advertise their capabilities in very flexible ways. For example, suppose an editor was capable of handling a number of file types, such as plain text and RTF files. It could do so by exporting a service object implementing Editor along with an Entry object saying that it can handle plain text and another Entry object saying that it can handle RTF files. The service implementation can just add more and more information about its capabilities without altering the basic interface.

To manage this way of adding information, we could have a FileType class , which would give information about the types of files handled:

 public Class FileType implements Entry {     public String type; // this is a MIME type     public FileType(String type) {        this.type = type;     } } 

For a text editor, the attribute set would be FileType("plain/text") . For an RTF editor, the attribute set would be FileType("application/rtf") .

For an editor capable of handling both plain text and RTF files, its capabilities would be given by using an array of entries:

 Entry[] entries = new Entry[] {new FileType("plain/text"),                                new FileType("application/rtf")                               }; 

On the other side, suppose a client wishes to find services that can handle the attributes that it requires. The client uses the same Entry class to do this. For any particular Entry , the client specifies both of the following:

• Which fields must match exactly (a non- null value)
• Which fields it does not care about (a null value)

For example, to search for a plain text editor, an entry like this would be used:

 Entry[] entries = new Entry[] {new FileType("plain/text")}; 

If any editor would do, the following entry could be used:

 Entry[] entries = new Entry[] {new FileType(null)}; 

Attribute Matching Mechanism

The attribute matching mechanism is pretty basic. For example, a printer typically has the capacity to print a certain number of pages per minute, but if it specifies this using an Entry , it actually becomes rather hard to find. A client can request a printer service in which it does not care about speed, or it can request a particular speed. It cannot ask for printers with a speed greater than some value. It cannot ask for a printer without a capability, such as anything except a color printer. An attribute must either match exactly or be ignored. The relational operators such as "<" and "!=" are not supported.

If you want to search for a printer with a particular speed, then printer speed capabilities may need to be given simpler descriptive values, such as "fast," "average," or "slow." Then, once you have a "fast" printer service returned to the client, it can perform a query on the service, itself, for the actual speed. This would be done outside of the Jini mechanisms, using whatever interface has been agreed on for the description of printers. A similar problem, that of finding a physically "close" service, is taken up in Chapter 13.

The attribute matching mechanism that was chosen by the Jini designers, of exact matches with wildcards, is comparatively easy to implement. It is a pity from the programmer's view that a more flexible mechanism was not used. One suggestion often made in the Jini mailing list is that there should be a boolean matches() method on the service object. However, that would involve unmarshalling the service on the locator in order to run the matches() method, and this would slow the lookup service down and generate a couple of awkward questions:

• What security permissions should the filter run with?
• What would happen if the filter modifies its arguments (deep copying to avoid this would cause further slowdowns)?

The ServiceDiscoveryManager ”discussed in Chapter 15 ”has the ability to do client-side filtering to partly rectify this problem.