Advertisement

Lookup servers versus name servers

To fully appreciate the flexibility and power of Jini's lookup service, it's useful to compare it to name servers such as the RMI registry. The RMI registry is similar to the Jini lookup service in that objects can be registered in either server, and clients can query both for objects. When a client queries either server for an object, the server sends the object across the network to the client.

The RMI registry is a name server, because each RMI remote object is associated with a character string name that is unique within that registry. To perform a query on an RMI registry, clients must specify that name. In return for the name, clients receive a stub object that serves as a remote reference to the remote object in the queried RMI registry.

Jini provides a much more expressive way to search for services than RMI. Jini services are registered with a service ID that is globally unique and permanently maintained by each service, a service object, and any number of attribute objects. Using the ServiceTemplate, clients can look up a service by service ID, by the Java type or types of the service object, and by wildcard and exact matching of the attributes. Whereas RMI requires that a client know the registered name of a desired remote object, Jini enables a client to just look for the type of service desired -- therefore enabling spontaneous networking. If you enter a LAN environment for the first time and you want to use a printer, you don't have to figure out the printer service's registered name; instead, you just look up the services that implement a well-known printer interface. Lookup by type also ensures that Jini clients will know how to use whatever is returned from their query, because they had to have knowledge of the type before sending their query.

On the other hand, the Jini lookup service does operate similar to a naming server in two ways. First, performing lookups by service ID is really looking up services by name. Just as the character string name of a remote object in RMI registry is unique, a service ID is a unique name for a Jini service. A Jini service ID differs from an RMI registry name only in its form and its scope of uniqueness. Whereas an RMI registry name is a character string, a Jini service ID is a 128-bit number. And whereas an RMI registry name is guaranteed to be unique only within the scope of each particular RMI registry server, a Jini service ID is supposed to be globally unique.

The other way in which a Jini lookup service operates as a naming server is that lookups by type are actually implemented by performing string comparisons of type names. As mentioned previously, to specify the kind of service desired, clients specify Java types. The types specified are most often interfaces, but can also be classes. Because developers of Jini clients must indicate the desired service with a Java type, he or she knows about the type at compile-time, and will therefore know how to use whatever object is returned.

To indicate a Java type, clients must pass to the service registrar's lookup() method an array of references to Class instances that represent the desired types in the client's virtual machine. Any registered service whose service object is an instance of each type specified by the client matches the lookup. When the lookup service looks through its set of registered services, however, it merely compares the type names of the types appearing in the client's Class[] array with the type names of the registered service objects. The lookup service doesn't compare any class information besides the type name.

Because the lookup service compares types by name only, two different types with the same name would match. Nevertheless, were the service object for such a mismatched type to arrive at the client, the deserialization process on the client side would detect the mismatch and throw an exception.

The reason the lookup service can get by with performing merely a string comparison of the type names, and ignoring all other class information, is that:

1. Java objects come with a global naming scheme that's supposed to make all fully qualified names unique. IBM, for example, is responsible for making sure no two types in the com.ibm namespace have the same name, and it is not supposed to let the world see anything it made whose name doesn't start with "com.ibm" (or the reverse form of any other Internet domain name it controls).
2. Java has a set of rules of binary compatibility that enable each named type to evolve without breaking pre-existing code that uses the earlier versions of the named type.
3. Java type names are intimately associated with an interface and a semantic contract that instances of that named type are supposed to fulfill. So a Java type name has more meaning than an arbitrarily assigned logical name.

The last item in the previous list is one of the most important differences between a traditional name server, such as RMI Registry, and the Jini lookup service. A Java type name is associated with an interface and a semantic contract that gives meaning to the name. That meaning should be the same worldwide because of the first item in the list, the recommended naming convention. The name assigned to a remote object registered in an RMI Registry, by contrast, is an arbitrarily chosen name that by itself says nothing about the services offered by the referenced remote object.

One final difference between a traditional name server and the Jini lookup server is that Jini service objects can in effect have multiple names. Objects can have many names because they can be instances of many different types. Thus an object that has two type names, "Printer" and "Copier" can be located by two different clients looking for either a "Printer" or "Copier" object.