Jini Lookup Services (LUSs) and the Discovery, Join, and Leasing protocols collectively allow a Jini system to accurately, efficiently, and automatically track the set of services currently available in dynamic environments. These capabilities provide a Jini technology system with a level of self-awareness, in that the system always knows which services are available to it, even though services are expected to come, go, and move around while the system is running.
When they start up, Jini clients and services "discover" Jini LUSs by multicasting (or unicasting) requests for Lookup Services. Each LUS responds to discovery requests by delivering its proxy, a Java object that implements the LUS interface, to the discovering client or service. Jini services then use the LUS proxies to "join" the Jini network by registering themselves in each LUS. Jini clients use the proxies to "lookup" services as they need them.
|Figure 1: Dynamic Networking with Jini Technology 1|
The discovery protocol also supports the late arrival of LUSs. At startup, and periodically thereafter, LUSs send out availability announcements. Interested Jini clients and services that are already up and running respond to those announcements by initiating unicast discovery requests back to the LUS. This also allows running LUSs to reconnect with clients and services after a network recovers from a failure.
As part of its registration with a LUS, a Jini service agrees to terms of a lease, which it negotiates with the LUS and which specifies how long the LUS will maintain the service's registration. If the service does not renew its lease before it expires, the LUS automatically drops the service's registration. Leasing helps a Jini system define network failures, which can be a tricky thing to do: how can you tell the difference between a slow network connection and a lost connection? Leasing enables the LUS and service to agree in advance about exactly how long is too long to wait. And, because lease terms are negotiated between the LUS and each registered service, their durations may vary from one service to another within the same LUS, or from one LUS to another for the same service. This gives you a level of flexibility that you may need to accommodate variations in availability requirements and network stability among different services within a single system.
Jini LUSs are themselves Jini services, so it's natural for them to come, go, move around, and change like any other component of a Jini system. If you take advantage of this self-referencing architecture you can be sure that the infrastructure supporting your Jini system will also be adaptive to change. For example, you can provide redundancy by simply running multiple LUS instances.