A common problem when using networks is the scenario that a client dies before
being able to shut down a server connection in a nice way. Solutions typically
involve some form of polling or keep-alive packets - either the client
regularly tells the server that it is still there, or the server makes the
rounds now and then asking every client whether it is still alive. A negative
answer means the end of the connection.
This behavior is often implemented in the lower layers of the protocol stack,
and therefore largely invisible to the application programmer. Invisible also
means uncontrollable - you cannot control how often these packets are sent,
and how many may return a negative result, without descending to lower layers.
Jini, naturally, has to tackle the same problem. The concept that has been
applied is not new, but it has been lifted to the application layer so that
the application programmer is in full control. The idea is that every resource
is leased - someone owns a resource (a service registration, a network
connection, whatever) and someone else wants it; the parties agree on a lease,
and as long as the lease is renewed regularly, access to the resource is
granted. Lessor and lessee agree together on the lease duration - a log-in
session, for example, would be leased for 8 hours, while a transaction may
know lease times as short as a minute before the lease expires.
The flexibility lies in the fact that a) you can control the lease time, and
thereby prevent unnecessary network traffic, and b) no-one cares /who/ renews
the lease: a client may go away but hand over its leases to a renewal service
first, so that when it returns it still has access to its resources.
Leases are a powerful concept, and Jini has a very nice library around
them. In fact, I would say that leases alone would be reason to include the
Jini class files in your development environment - you can benefit greatly
from them without using any single Jini feature.