Entries are used to pass additional information about services that clients can use to decide if a particular service is what it wants.
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 an object, albeit in serialised form. The server can optionally register sets of attributes along with the service object. Each set is given by an instance of a type or class. So 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 shown in 4.1.
A client can search for a suitable editor in two ways
ImageEditor
Editor
with the additional information that it can
handle a certain type of file
ImageEditor.class.
The Jini Entry
class is designed to help with the second situation by specifying a
superclass object such as Editor.class and allowing
the additional information to be given in the request by adding
extra objects.
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 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;
}
}
FileType("plain/text").
For a 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, 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
null value)
Entry[] entries = new Entry[] {new FileType("plain/text")};
Entry[] entries = new Entry[] {new FileType(null)};
The matching mechanism is pretty basic. A printer typically has the capacity to print a
certain number of pages per minute. If it specifies this using an
Entry, 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 request 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. A similar problem, that of finding a physically ``close'' service is taken up in the chapter on ``More Complex Examples''.
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. One suggestion often made in the Jini
mailing list is that there
should be a boolean matches() method on the service object.
However, it would involve un-marshalling the service on the locator in order
to run the
matches() method and this suffers from a variety of problems
ClientLookupManager - discussed in a much later chapter -
has the ability to do client-side filtering to partly rectify this.)
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. However, when it comes to comparing them, this is usually done on the lookup service and they are not reconstituted on the lookup service. 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.
This to make it easier to perform ``wildcarding'' for matching
(see next chapter for details). A wildcard for any object can be
the ``pattern'' null which will work for any class,
including wrapper classes such as Boolean (on the
other hand, what is the wildcard for boolean:
true or false?).
The only fields of interest are public, non-static, non-transient and non-final.
An entry class must have a no-args constructor.
The class AbstractEntry implements the Entry interface,
and is designed as a convenience class. It implements methods such
as equals() and toString().
An application would probably want to subclass this instead of
implementing Entry.
In addtion, Sun's implementation of Jini contains a further set of
convenience classes, all subclassed out of AbstractEntry.
These require the jini-ext.jar file and 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.
The primary intention of entries is to provide extra information about services so that clients can decide whether or not they are the services they want to use. An expectation in this is that the information in an entry is primarily static. However, entries are objects, and could also implement behaviour as well as state. This should not be used to extend the behaviour of a service, since all service behaviour should be captured in the service interface specification.
A good example of a ``non-static'' Entry
is given by ServiceType, which is an
abstract subclass of AbstractEntry. This contains ``human
oriented'' information about a service, and contains abstract methods such
as String getDisplayName(). This method is intended to provide a
localized name for the service. Localisation (e.g.
producing an appropriate French name of the service
for the various French-speaking communities)
can only be done on the client side, and will require code to execute in the
client to examine the locale and produce a name.
Another use is to define the user interface for a service.
Services do not have or require user interfaces for human users, since they are
defined by Java interfaces that can be called by any other Java objects.
However, some services may wish to offer a way of interacting with them
by means of a user interface, and this involves much executable code.
Since it is not part of the service itself, this should be left in
suitable Entry objects.
This topic is looked at in detail in a much later chapter.
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.
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