Entries are used to pass additional information about services that clients can use to decide if a particular service is what it wants.

1. Entry class
   1. Simplistic
2. Restrictions on entries
3. Convenience Classes
4. Summary

When a service registers itself, it does so with a set of attributes. Each set is given by an instance of a type or class. What is stored on each service locator is an instance of a class along with a set of attribute entries. For example, a set of file editors may be available as services. Each editor is capable of editing different types of file as in



A client can search for a suitable editor in two ways

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

The Entry class also allows services to advertise their capabilities in ways that would otherwise require use of multiple inheritance, which is not available in Java. Suppose an editor belonged to class SuperEditor which can handle plain text, RTF files and image files. In a multiple inheritance system it would do so by subclassing from all of the classes. In Jini, it just advertises itself as being an Editor, but has entries attached for each of the types that it can handle.

To manage this, we would have a class FileType which gives information about the types of file handled:

public Class FileType implements Entry {
    public String type; // this is a MIME type

    public FileType(String type) {     
       this.type = type;
    }
}

For the SuperEditor, its capabilities would be given by using an array of entries:

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

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

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

This is pretty crude. A printer typically has the capacity to print a certain number of pages per minute. If it specifies this, then it actually makes it rather hard to find! A client can request a printer service in which it does not care about speed, or for 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 at 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 its actual speed. This would be done outside of the Jini mechanisms, using whatever interface has been agreed for the description of printers.

The mechanism chosen, 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.

Entries are shipped around in marshalled form. Exported service objects are serialized, moved around and reconstituted as objects at some remote client. Entries are similarly serialized and moved around, but are not reconstituted. So when it comes to comparing an entry from a service and an entry from a client request, it is the serialized forms that are compared.

An entry cannot have as field one of the primitive types such as int or char. If one of these fields is required, then it must be wrapped up in a class such as Integer or Character.

The only fields of interest are public, non-static, non-transient and non-final.

The class AbstractEntry is a subclass of Entry, and is designed as a convenience class. It implements methods such as equals() and toString(). Hoever, it doesn't really seem to add much that would justify using it, in my opinion.

In addtion, Sun's implementation of Jini contains a further set of convenience classes, all subclassed out of AbstractEntry. They are

• Address - the address of the physical component of a service.
• Comment - a free-form comment about a service.
• Location - the location of the physical component of a service. This is distinct from the Address class in that it can be used alone in a small, local organization.
• Name - the name of a service as used by users. A service may have multiple names.
• ServiceInfo - generic information about a service. This includes the name of the manufacturer, the product, and the vendor.
• ServiceType - human-oriented information about the "type" of a service. This is not related to its data or class types, and is more oriented towards allowing someone to determine what a service (for example, a printer) does and that it is similar to another, without needing to know anything about data or class types for the Java platform.
• Status - the base class from which other status-related entry classes may be derived.

For example, the Address class contains

String country;
String locality;           // City or locality name.
String organization;       // Name of the company or organization that provides this service.
String organizationalUnit; // The unit within the organization that provides this service.
String postalCode;         // Postal code.
String stateOrProvince;    // Full name or standard postal abbreviation of a state or province.
String street;             // Street address.

An entry is additional information about a service. A service may have any number of entries. Clients requests services by class and by entries, using a simple matching system. There are a number of convenience classes that subclass Entry.