Sponsored Link •
How Jini works
Jini defines a runtime infrastructure that resides on the network and provides mechanisms that enable you to add, remove, locate, and access services. The runtime infrastructure resides on the network in three places: in lookup services that sit on the network; in the service providers (such as Jini-enabled devices); and in clients. Lookup services are the central organizing mechanism for Jini-based systems. When new services become available on the network, they register themselves with a lookup service. When clients wish to locate a service to assist with some task, they consult a lookup service.
The runtime infrastructure uses one network-level protocol, called discovery, and two object-level protocols, called join and lookup. Discovery enables clients and services to locate lookup services. Join enables a service to register itself in a lookup service. Lookup enables a client to query a lookup service for services that can help the client accomplish its goals.
The discovery process
Discovery works like this: Imagine you have a Jini-enabled disk drive that offers a persistent storage service. As soon as you connect the drive to the network, it broadcasts a presence announcement by dropping a multicast packet onto a well-known port. Included in the presence announcement is an IP address and port number where the disk drive can be contacted by a lookup service.
Lookup services monitor the well-known port for presence announcement packets. When a lookup service receives a presence announcement, it opens and inspects the packet. The packet contains information that enables the lookup service to determine whether or not it should contact the sender of the packet. If so, it contacts the sender directly by making a TCP connection to the IP address and port number extracted from the packet. Using RMI, the lookup service sends an object, called a service registrar, across the network to the originator of the packet. The purpose of the service registrar object is to facilitate further communication with the lookup service. By invoking methods on this object, the sender of the announcement packet can perform join and lookup on the lookup service. In the case of the disk drive, the lookup service would make a TCP connection to the disk drive and would send it a service registrar object, through which the disk drive would then register its persistent storage service via the join process.
The join process
Once a service provider has a service registrar object, the end product of discovery, it is ready to do a join -- to become part of the federation of services that are registered in the lookup service. To do a join, the service provider invokes the
method on the service registrar object, passing as a parameter an
object called a service item, a bundle of objects that
describe the service. The
register() method sends a copy
of the service item up to the lookup service, where the service item is
stored. Once this has completed, the service provider has finished the
join process: its service has become registered in the lookup service.
The service item is a container for several objects, including an object called a service object, which clients can use to interact with the service. The service item can also include any number of attributes, which can be any object. Some potential attributes are icons, classes that provide GUIs for the service, and objects that give more information about the service.
Service objects usually implement one or more interfaces through which
clients interact with the service. For example, a lookup service is a
Jini service, and its service object is the service registrar. The
register() method invoked by service providers during
join is declared in the
interface (a member of the
which all service registrar objects implement. Clients and
service providers talk to the lookup service through the service
registrar object by invoking methods declared in the
ServiceRegistrar interface. Likewise, a disk drive would
provide a service object that implemented some well-known storage
service interface. Clients would look up and interact with the disk
drive by this storage service interface.
The lookup process
Once a service has registered with a lookup service via the join process, that service is available for use by clients who query that lookup service. To build a distributed system of services that will work together to perform some task, a client must locate and enlist the help of the individual services. To find a service, clients query lookup services via a process called lookup.
To perform a lookup, a client invokes the
on a service registrar object. (A client, like a service provider, gets
a service registrar through the process of discovery, as
described earlier in this article.) The client passes as an argument to
lookup() a service template, an object that
serves as search criteria for the query. The service template can
include a reference to an array of
Class objects. These
Class objects indicate to the lookup service the Java type
(or types) of the service object desired by the client. The service
template can also include a service ID, which uniquely
identifies a service, and attributes, which must exactly match the
attributes uploaded by the service provider in the service item. The
service template can also contain wildcards for any of these fields. A
wildcard in the service ID field, for example, will match any service
lookup() method sends the service template to the
lookup service, which performs the query and sends back zero to many
matching service objects. The client gets a reference to the matching
service objects as the return value of the
In the general case, a client looks up a service by Java type, usually
an interface. For example, if a client needed to use a printer, it would
compose a service template that included a
for a well-known interface to printer services. All printer services
would implement this well-known interface. The lookup service would
return a service object (or objects) that implemented this interface.
Attributes can be included in the service template to narrow the number
of matches for such a type-based search. The client would use the
printer service by invoking on the service object methods declared in
the well-known printer service interface.