Java Reference
In-Depth Information
Another way Jini provides flexibility and ease of use is in how the lookup services are discovered. Although it is
possible to specify on what machine(s) a lookup service is running, lookup services can be located dynamically at
runtime. So neither the Jini service nor the service consumer need to know where the lookup service is running.
Within Jini the part of a Jini service that is transported across the network is called the Service proxy even though that object may be the
full Jini service.
Leases
One of Jini's most distinguishing features is
leases.
Every resource a service consumer uses, or is interested in, is
leased. A lease is an acknowledgement from the user of the service to the service (holder of the resource) that it is
still interested in that particular resource. The lease has a duration after which the lease expires and the resource
can be reclaimed. If the service wants to continue to use the resource it has to renew the lease. If the service
consumer fails to renew the lease (no longer interested, network failure, and so on), the resource can be reclaimed
and re-used.
The lease is not a guarantee. A service consumer can faithfully maintain the lease, but the lease can still fail. The
service can cancel leases and free resources whenever it sees fit. The recommendation here is of course that the
service should only do that when necessary. It can even happen while the service consumer is using the service.
However, lease failure is not as devastating as it may seem. You have already recognized that the network is
unreliable, so the service consumer has to be prepared to deal with the unavailability.
Suppose the leased resource is a telephone line service and the service has 10 phone lines available. Normally
when those 10 lines are in use and a new line is requested, it will be unavailable. But suppose a fire has broken
out, the need for a phone line is top priority. The phone line service cancels the lease on one of the phone lines,
claims the resource (the phone line) and makes it available for the call to the fire department.
The lease concept is almost everywhere. When a service registers with the lookup service, one of the things the
service receives back is a
net.jini.core.lease.Lease
instance. The service uses that object to cancel or renew
the lease it has on the lookup service. When the service fails to renew the lease (or cancels it), it will be removed
from the lookup service. This practice keeps the lookup service up to date.
Distributed Events
The traditional Java event handling is not suitable for distributed events. One reason is that not a single method in
a listener interface throws a
RemoteException
, which is required for the listener to be in another address space.
Furthermore, the event objects keep a reference to the source. If that source is a GUI component, that component
has to be serialized to be sent across the network. The trouble is that this results in the
entire
graphical user
interface being serialized and sent, because all components keep a reference to their parent. In distributed
programming the objects have to be as small as possible. The last reason is that the current event handling system
does not support leases.
The Jini event handling system has to keep the uncertainty of the network in mind. Instead of having many
different listener interfaces, Jini only provides one,
net.jini.core.event.EventListener
, with only one
listener method
notify(net.jini.core.event.RemoteEvent re)
. And the
notify
method throws two
exceptions:
UnknownEventException
and
RemoteException
.
The
RemoteEvent
is intended to be as small as possible, while still carrying the information required by the
listener. It extends from
java.util. EventObject
, so it contains a source (the remote service), an event ID, a
handback object, and a sequence number. The event ID serves as an identifier to the specific events the listener
has registered to. The handback object is, as the name suggests, the object that the listener provides when
registering and that the event source hands back to listener when the event occurs (see “Pattern Use” in this
section). Finally the sequence number is provided for the uncertainty in the network. Events could arrive out of
order or some may just disappear. It is up to the listener what action to take if events arrive out of order.
The event ID and the sequence number are unknown to the listener before registering. When the listener registers,
the event source returns an instance of
net.jini.core.event.EventRegistration
, which contains the eventID,
the current sequence number, a
Lease
object, and a reference to the source.
Pattern Use
HOPP
(see page 189): When a Jini client (either a service wanting to register or a service consumer wanting to
look a service up) wants to use lookup service, it first locates one or more instances through the discovery
