`
`
`
`“RETESET
`
`THE JINIDISTRIBUTED LEASING SPECIFICATION
`
`143
`
`long getExpiration();
`void cancelQ throws UnknownLeaseException,
`RemoteException:
`void renew(long duration) throws LeaseDeniedException,
`UnknownLeaseException,
`RemoteException:
`
`void setSerialFormat(int format);
`int getSerialFormat(Q);
`LeaseMap createLeaseMap(long duration);
`boolean canBatch(Lease lease);
`
`} P
`
`articular instances of the Lease type will be created by the grantors of a
`lease and returned to the holder of the lease as part of the return value from a call
`that allocates a leased resource. The actual implementation of the object, includ-
`ing the way (if any) in which the Lease object communicates with the grantor of
`the lease, is determined by the lease grantor and is hidden from the lease holder.
`The interface defines two constants that can be used when requestingalease.
`The first, FOREVER, can be used to request a lease that never expires. When granted
`such a lease, the lease holderis responsible for ensuri ng that the leased resourceis
`freed when no longer needed. The second constant, ANY, is used by the requestor
`to indicate that no particular lease timeis desired and that the grantorofthe lease
`should supply a time that is most convenientfor the grantor.
`If the requestis for a particular duration, the lease grantoris required to grant
`a lease of no morethan the requested period oftime. A lease may be granted for a
`periodof time shorter than that requested.
`A secondpair of constants is used to determine the formatusedin theserial-
`ized form for a Lease object; in particular, the serialized form thatis used to rep-
`resent the time at which the lease expires. If the serialized format is set to the
`value DURATION,the serialized form will convert the time oflease expiration into a
`duration (in milliseconds) from the timeof serialization. This form is best used
`whentransmitting a Lease object from one address space to another (such as via
`an RMIcall) where it cannot be assumed that the address spaces have sufficiently
`synchronizedclocks,If the serialized formatis set to ABSOLUTE,the time of expi-
`ration will be stored as an absolute time, calculated in termsof milliseconds since
`the beginning ofthe epoch.
`The first method in the Lease interface, getExpi ration, returns a long that
`indicates the time,relative to the current clock, that the lease will expire, Follow-
`ing the usual convention in the Java programming language, this time is repre-
`sented as milliseconds from the beginning of the epoch, and can be used to
`
`i
`
`
`
`156
`
`156
`
`

`

`pS _
`
`144
`
`BASIC OPERATIONS
`
`comparethe expiration time of the lease with the result ofa call to obtain the cur-
`rent time, java. lang.System.currentTimeMillis.
`The second method, cance1, can be used by the lease holder to indicate thatit
`is no longer interested in the resource or information held by the lease. If the
`leased information or resource could cause a callback to the lease holder (or some
`other object on behalf of the lease holder), the lease grantor should not issue such
`a callback after the lease has been cancelled. The overall effect of a cance] call is
`the same as lease expiration, but instead of happening atthe end of a pre-agreed
`duration, it happens immediately. If the lease being cancelled is unknownto the
`lease grantor, an UnknownLeaseExceptionis thrown. The method can also throw
`a RemoteException if the implementation of the method requires calling a
`remote object that is the lease holder.
`The third method, renew, is used to renew a lease for an additional period of
`time. The length of the desired renewalis given, in milliseconds, in the parameter
`to the call. This duration is not addedto the original lease, but is used to determine
`a new expiration time for the existing lease. This method has no return value; if
`the renewal is granted, this is reflected in the lease object on which the call was
`made. If the lease grantor
`is unable or unwilling to renew the lease, a
`RenewFai ledException is thrown. If a renewalfails, the lease is left intact for the
`same duration that was in force prior to the call
`to renew. If the lease being
`renewed is unknownto the lease grantor, an UnknownLeaseException is thrown.
`The method can also throw a RemoteException if the implementation of the
`method requires calling a remote object that is the lease holder.
`Two methods are concerned with the serialized format of a Lease object. The
`first, setSerialFormat, takes an integer that indicates the appropriate formatto
`use whenserializing the format. The current supported formats are a duration for-
`mat that stores the length of time (from the time of serialization) before the lease
`expires, and an absolute format, which stores the time (relative to the current
`clock) that the lease will expire. The absolute format should be used whenserial-
`izing a Lease object for transmission from one machine toanother; the durational
`format should be used when storing a Lease object on stable store that will be
`read backlater by the same process or machine. Thedefault serialization formatis
`durational. The second method, getSerialForm, returns an integer indicating the
`formatthat will be used to serialize the Lease object.
`The last two methodsare used toaid in the batch renewalor cancellation of a
`group of Lease objects. Thefirst of these, createLeaseMap,creates a Map object
`that can contain leases whose renewalor cancellation can be batched, and adds the
`current lease to that map. The current lease will be renewed for the duration indi-
`cated by the argument to the method when all of the leases in the LeaseMap are
`renewed. The second method, batchWith(Lease lease), returns a boolean value
`indicating whether or not the lease given as an argumentto the method can be
`
`|
`
`
`
`157
`
`157
`
`

`

`Nie}
`
`fonia")
`$<)whie
`i=}
`
`(aD
`
`145
`
`THEJINI DISTRIBUTED LEASING SPECIFICATION
`batched (in renew and cance] calls) with the currentlease. Whetheror not two
`Lease objects can be batched is an implementation detail determined by the
`objects.
`Three types of Exception objects are associated with the basic lease inter-
`face. All of these are used in the Leaseinterface itself, and two can be used by
`methodsthat grant access to a leased resource.
`The RemoteException is imported from the package java. rmi. This excep-
`tion is used to indicate a problem with any communication that might occur
`between the lease holder and the lease grantorif those objects are in separate vir-
`tual machines. The full specification ofthis exception can be found in the Java
`Remote Method Invocation Specification.
`The UnknownLeaseExceptionis used to indicate that the Lease object used
`is not known to the grantor of the lease. This can occur whenalease expires, or
`when a copyofa lease has been cancelled by someother lease holder. This excep-
`tion is defined as:
`
`package net.jini.core. lease;
`
`public class UnknownLeaseException extends LeaseException {
`public UnknownLeaseException()
`{
`super();
`
`} p
`
`}
`
`ublic UnknownLeaseException(String reason) {
`super(reason) ;
`
`} T
`
`he final exception defined is the LeaseDeniedException, which can be
`thrownbyeither a call to renew or a call to an interface that grants access to a
`leased resource. This exception indicates that the requested lease has been denied
`by the resource holder. The exception is defined as:
`package net.jini.core. lease;
`
`public class LeaseDeniedException extends LeaseException {
`public LeaseDeniedException() {
`super ();
`
`} p
`
`}
`
`ublic LeaseDeniedException(String reason) {
`super(reason):
`
`158
`
`158
`
`

`

`
`
`146
`
`BASIC OPERATIONS
`
`The LeaseException superclassis defined as:
`
`package net.jini.core. lease;
`
`public class LeaseException extends Exception {
`public LeaseException() {
`super();
`
`} p
`
`}
`
`ublic LeaseException(String reason) {
`super (reason) ;
`
`} T
`
`he final basic interface defined for leasing is that of a LeaseMap, which
`allows groups of Lease objects to be renewed or cancelled using a single opera-
`tion. The LeaseMap interfaceis:
`
`package net.jini.core. lease;
`
`import java.rmi.RemoteException;
`
`public interface LeaseMap extends java.util.Map {
`boolean canContainKey(Object key);
`void renewAl1()
`throws LeaseMapException, RemoteException;
`void cancelAl1(€)
`throws LeaseMapException, RemoteException;
`
`}
`
`A LeaseMap is an extension of the java.util.Map class that associates a Lease
`object with a Long. The Long is the duration for which the lease should be
`renewed wheneverit is renewed. Lease objects and associated renewal durations
`can be entered and removed from a LeaseMap using the usual Map methods. An
`attempt to add a Lease object to a map containing other Lease objects for which
`Lease.canBatch would return false will cause an I111legalArgumentException
`to be thrown,as will attempts to add a key that is not a Lease objector a value that
`is not a Long.
`The first method defined in the LeaseMap interface, canContainKkey, takes a
`Lease object as an argumentand returns true if that Lease object can be added to
`the Map and false otherwise. A Lease object can be added to a Map if that Lease
`object can be renewed in a batch with the other objects in the LeaseMap. The
`requirements for this depends on the implementation of the Lease object.
`The second method, renewA11, will attempt to renew all of the Lease objects
`in the LeaseMap for the duration associated with the Lease object. If all of the
`Lease objects are successfully renewed, the method will return nothing. If some
`
`
`
`159
`
`159
`
`

`

`
`
`THE JINT DISTRIBUTED LEASING SPECIFICATION
`
`Lease objects fail to renew,those objects will be removed from the LeaseMap and
`will be containedin the thrown LeaseMapException.
`The third method, cance1A11, cancels all the Lease objects in the LeaseMap.
`If all cancels are successful, the method returns normally and leaves all leases in
`the map. If any of the Lease objects cannot be cancelled, they are removed from
`the LeaseMapandthe operation throws a LeaseMapException.
`The LeaseMapException class is defined as:
`
`package net.jini.core. lease;
`
`import java.util.Map;
`
`public class LeaseMapException extends LeaseException {
`public Map exceptionMap;
`public LeaseMapException(String s, Map exceptionMap)
`super(s);
`this.exceptionMap = exceptionMap;
`
`{
`
`}
`
`that maps Lease
`Objects of type LeaseMapException contain a Map object
`objects (the keys) to Exception objects (the values). The Lease objects are the
`ones that could not be renewed or cancelled, and the Exception objectsreflect the
`individual failures. For example, if a LeaseMap. renew call fails because one of
`the leases has already expired, that lease would be taken out ofthe original
`LeaseMap and placed in the Map returned as part of the LeaseMapException
`object with an UnknownLeaseException object as the corresponding value.
`
`LE.2.3 Leasing and Time
`
`The duration of a lease is determined whenthelease is granted (or renewed). A
`lease is granted for a duration rather than until some particular momentoftime,
`since such a grant does not require that the clocks used bythe client and the server
`be synchronized.
`The difficulty of synchronizing clocks in a distributed system is well known.
`The problem is somewhat moretractable in the case ofleases, which are expected
`to be for periods of minutes to months, as the accuracy of synchronization
`required is expected to be in terms of minutes rather than nanoseconds. Overa
`particular local group of machines, a time service could be used that would allow
`this level of synchronization.
`However, leasing is expected to be used byclients and servers that are widely
`
`
`
`distributed and mightnotshare a particular time service. In such a case, clock drift eReean?TLLPSETTTEETEES
`
`
`160
`
`160
`
`

`

`148
`
`SERIALIZED FORMS
`
`of many minutes is a common occurrence. Becauseofthis, the leasing specifica-
`tion has chosento use durations rather than absolute time.
`The reasoning behind such a choice is based on the observation that the accu-
`racy of the clocks used in the machines that make up a distributed system is
`matched much moreclosely than the clocks on those systems. While there may be
`minutes ofdifference in the notion of the absolute time held by widely separated
`systems, there is muchless likelihood of a significant difference over the rate of
`change of time in those systems. While there is clearly some difference in the
`notion of duration between systems (if there were not, synchronization for abso-
`lute time would be mucheasier), that difference is not cumulative in the way
`errors in absolute timeare.
`This decision does mean that holders ofleases and grantors ofleases needto
`be aware of some of the consequences of the use of durations. In particular, the
`amount of time needed to communicate between the lease holder and the lease
`grantor, which may vary from call to call, needs to be taken into account when
`renewinga lease. If a lease holder is calculating the absolute time (relative to the
`lease holder’s clock) at which to ask for a renewal, that time should be based on
`the sum of the duration of the lease and the time at which the lease holder
`requested the lease, not on the duration and the time that the lease holder received
`the lease.
`
`LE.2.4 Serialized Forms
`
`
`
`
` Class serialVersionUID Serialized Fields
`
`
`
`LeaseException
`
`—7902272546257490469L all public fields
`
`UnknownLeaseException
`
`—2921099330511429288L none
`
`LeaseDeniedException
`
`5704943735577343495L none
`
`
`
`LeaseMapException —4854893779678486122L none
`
`
`
`161
`
`161
`
`

`

`
`
`
`
`THE JINI DISTRIBUTED LEASING SPECIFICATION
`
`
`LE.3 Example Supporting Classes
`
`Ti basic Lease interface allows leases to be granted by one object and handed
`to another as the result of a call that creates or provides access to some leased
`resource. The goal of the interface is to allow as much freedom as possible in
`implementation to both the party that is granting the lease (and thusis giving out
`the implementation that supports the Lease interface) and the party that receives
`the lease.
`However, a numberof classes can be supplied that can simplify the handling
`of leases in some common cases, We will describe examples of these supporting
`classes and show howtheseclasses can be used with leased resources.
`
`LE.3.1 A Renewal Class
`
`One of the commonpatterns with leasing is for the lease holder to request a lease
`with the intention of renewing the lease until it is finished with the resource. The
`period of time during which the resource is needed is unknown at the time of
`requesting the lease, so the requestor wants the lease to be renewed until an unde-
`termined time in the future. Alternatively, the lease requestor might know how
`long the lease needs to be held, but the lease holder might be unwilling to grant a
`lease for the full period of time. Again, the pattern will be to renew the lease for
`some period oftime.
`If the lease continues to be renewed, the lease holder doesn’t want to be both-
`ered with knowing aboutit, but if the lease is not renewed for some reason, the
`lease holder wants to be notified. Such a notification can be done using the usual
`inter-address space mechanismsfor event notifications, by registering a listenerof
`the appropriate type. This functionality can be supplied by a class with an inter-
`face like the following
`
`class LeaseRenew {
`LeaseRenew(Lease toRenew,
`long renewTil,
`LeaseExpireListener listener) {...}
`
`Me)
`
`
`ab
`we
`
`162
`
`162
`
`

`

`
`
`150
`
`A RENEWALCLASS
`
`]
`
`|
`|
`
`|
`
`void addRenew(Lease toRenew,
`long renewTil,
`LeaseExpireListener listener) {..}
`long getExpiration(Lease forLease)
`throws UnknownLeaseException {...}
`void setExpiration(Lease forLease, long toExpire)
`throws UnknownLeaseException {...}
`void cancel(Lease toCancel)
`throws UnknownLeaseException {...}
`void setLeaseExpireListener(Lease forLease,
`LeaseExpireListener listener)
`throws UnknownLeaseException {...}
`void removeLeaseExpireListener(Lease forLease)
`throws UnknownLeaseException {..}
`
`}
`The constructorofthis class takes a Lease object, presumably returned from some
`call that reserved a leased resource; an initial time indicating the time until which
`the lease should be renewed; andanobjectthatis to be notified if a renewal fails
`before the time indicated in renewTi1. This returns a LeaseRenew object, which
`will have its own thread of control that will do the lease renewals.
`Once a LeaseRenewobject has beencreated, other leases can be added to the
`set that are renewed by that object using the addRenewcall. This call takes a
`Lease object, an expiration time or overall duration, and a listener to be informed
`if the lease cannot be renewed prior to the time requested. Internally to the
`LeaseRenew object, leases that can be batched can be placed into a LeaseMap.
`The duration of a particular lease can be queried by a call to the method
`getExpiration. This method takes a Lease object and returns the time at which
`that lease will be allowedto expire by the LeaseRenew object. Notethatthis is dif-
`ferent from the Lease. getExpiration method, whichtells the time at which the
`lease will expireif it is not renewed.If there is no Lease object correspondingto
`the argument for this call being handled by the LeaseRenew object,
`an
`UnknownLeaseException will be thrown. This can happen either when no such
`Leasehasever been given to the LeaseRenew object, or when a Lease object that
`has been held has already expired or been cancelled. Notice that since this object
`is assumed to be in the same address space as the object that acquired the lease,
`we can assumethat it shares the same clock with that object, and hence can use
`absolute time rather than a duration-based system.
`The setExpi ration method allowsthecaller to adjust the expiration time of
`any Lease object held by the LeaseRenewobject. This method takes as arguments
`the Lease whose time of expiration is to be adjusted and the new expiration time.
`
`
`
`163
`
`163
`
`

`

`
`
`
`
`
`“vePoRREARENCOTaLAANTINT
`
`
`Te JINI DISTRIBUTED LEASING SPECIFICATION
`
`
`151
`
`[f no lease is held by the LeaseRenew object corresponding to the first argument,
`an UnknownLeaseException will be thrown.
`A call to cance will result in the cancellation of the indicated Lease held by
`the LeaseRenew object. Again, if the lease has already expired on that object, an
`UnknownLeaseException will be thrown. It is expected thata call to this method
`will be made if the leased resource is no longer needed, rather than just dropping
`all references to the LeaseRenew object.
`The methods setLeaseExpireListener and removeLeaseExpireListener
`allow setting and unsetting the destination of an event handler associated with a
`particular Lease object held by the LeaseRenew object. The handler will be called
`‘f the Lease object expires before the desired duration period is completed. Note
`that one of the properties of this example is that only one LeaseExpireListener
`can be associated with each Lease.
`
`LE.3.2 A Renewal Service
`
`Objects that hold a lease that needs to be renewed may themselves be activatable,
`and thus unable to ensure that they will be capable of renewing a lease at some
`particular time in the future (since they mightnot be active at that time). For such
`objects it might make sense to hand the lease renewal duty off to a service that
`could take care of lease renewalfor the object, allowing that object to be deacti-
`vated without fear of losing its lease on some other resource.
`The most straightforward way of accomplishing this is to hand the Lease
`object off to some object whose job it is to renew leases on behalf of others. This
`object will be remote to the objects to which it offers its service (otherwise it
`would be inactive when the others become inactive) but might be local to the
`machine; there could even be suchservices that are located on other machines.
`The interface to such an object might look somethinglike:
`
`|
`|
`
`interface LeaseRenewService extends Remote {
`EventRegistration renew(Lease toRenew,
`long renewTil,
`RemoteEventListenter notifyBeforeDrop,
`MarshalledObject returnOnNotify)
`throws RemoteException;
`void onRenewFai lure(Lease toRenew,
`RemoteEventListenter toNotify,
`MarshalledObject returnOnNotify)
`throws RemoteException, UnknownLeaseException;
`
`
`
`164
`
`164
`
`

`

`
`
`152
`
`A RENEWAL SERVICE
`
`Thefirst method, renew, is the request to the object to renew a particular lease on
`behalf of the caller. The Lease object
`to be renewed is passed to the
`LeaseRenewService object, along with the length of time for which the leaseis to
`be renewed. Since we are assuming that this service might not be on the same
`machine as the object that acquired the original lease, we return to a duration-
`based time system, since we cannot assumethat the two systems have synchro-
`nized clocks.
`Requests to renew a Lease are themselves leased. The durationofthe leaseis
`requested in the duration argumentto the renew method, andthe actual time of the
`lease is retumed as part of the EventRegistration return value. While it might
`seem odd to lease the service of renewing other leases, this does not cause an infi-
`nite regress. It is assumed that the LeaseRenewService will grant leases that are
`longer (perhaps significantly longer) than those in the leases thatit is renewing. In
`this fashion, the LeaseRenewService can act as a concentrator for lease renewal
`messages.
`The renew method also takes as parameters a RemoteEventListener and
`MarshalledObject objects to be passed to that RemoteEventListener. This is
`because part of the semantics of the renew call is to register interest in an event
`that can occur within the LeaseRenewService object. The registration is actually
`for a notification before the lease granted by the renewal service is dropped. This
`event notification can be directed back to the object that is the client of the
`renewal service, and will (if so directed) cause the object to be activated (if it is
`not already active). This gives the object a chance to renew the lease with the
`LeaseRenewService object before that lease is dropped.
`The second methad, onRenewFai lure, allows the client to register interest in
`the LeaseRenewService being unable to renew the Lease supplied as an argu-
`ment to the call. This call also takes a RemoteEventListener object that is the
`target of the notification, and a Marshal ledObject that will be passed as part of
`the notification. This allows the client to be informed if the LeaseRenewService
`is denied a lease renewal during the lease period offered to the client for such
`renewal. This call does not take a time period for the event registration, but instead.
`will have the same duration as the leased renewal associated with the Lease object
`passed into the call, which should be the same as the Lease object that was sup-
`plied in a previous invocation of the method renew. If the Lease is not known to
`the LeaseRenewService object, an UnknownLeaseException will be thrown.
`There is no need for a method allowing the cancellation of a lease renewal
`request. Since these requests are themselves leased, cancelling the lease with the
`LeaseRenewServicewill cancel both the renewing of the lease and any event reg-
`istrations associated with that lease.
`
`
`
`165
`
`165
`
`

`

`(LE)
`
`ent
`
`166
`
`166
`
`

`

`
`
`
`
`THE JIN! DISTRIBUTED EVENT SPECIFICATIONdefinesthe distributed event
`programming model used throughout the Jini architecture. These are
`general-purpose events that can be used by any service
`for eventnotifications. The event modelis specifically
`aN designed to allowfor useful third parties that help
`either the sender orreceiver ofthe event. As you will
`see, the lookup service uses these events to notify
`
`interested parties of changesto its contents.
`
`E'
`
`alle
`ren
`
`ad
`kin
`
`E\
`
`Pre
`sid
`usi
`
`wl
`asi
`
`thi
`ev
`
`ot
`
`Cz
`re
`
`
`
`167
`
`167
`
`

`

`
`
` Sacer ET EETcn
`an
`
`
`
`
`
`
`
`alla,C/Noulddaoe
` sacl
`
`The Jinl Distributed Event
`Specification
`
`EV.1 Introduction
`
`Tue purposeofthe distributed eventinterfaces specified in this documentis to
`allow an object in one Java virtual machine (JVM)toregisterinterest in the occur-
`rence of some event occurring in an object in some other JVM, perhaps running on
`a different physical machine, andto receive a notification when an eventofthat
`kind occurs.
`
`EV.1.1 Distributed Events and Notifications
`
`Programs based on an objectthat is reacting to a change of state somewhere out-
`side the object are common ina single address space. Such programs are often
`used for interactive applications in which user actions are modeled as events to
`which other objects in the program react. Delivery of such local events can be
`assumed to be well ordered, very fast, predictable, and reliable. Further, the entity
`that is interested in the event can be assumed to always want to know about the
`event as soon as the event has occurred.
`The samestyle of programmingis useful in distributed systems, where the
`object reacting to an eventis in a different JVM, perhaps onadifferent physical
`machine, from the one on which the event occurred. Just as in the single-JVM
`case,
`the logic of such programs is often reactive, with actions occurring in
`tesponse to some changein state that has occurred elsewhere.
`A distributed event system hasa different set of characteristics and require-
`ments than a single-address-space event system. Notifications of events from
`
`155
`
`
`
`168
`
`168
`
`

`

`156
`
`GOALS AND REQUIREMENTS
`
`remote objects may arrive in different orders on different clients, or may not arrive
`at all. The time it takes for a notification to arrive may be long (in comparison to
`the time for computation at either the object that generated the notification or the
`object interested in the notification). There may be occasions in which the object
`wishing the event notification does not wish to have that notification as soon as
`possible, but only on some schedule determined by the recipient. There may even
`be times when the object that registered interest in the event is not the object to
`which a notification of the event should be sent.
`Unlike the single-address-space notion of an event, a distributed event cannot
`be guaranteed to be delivered in a timely fashion. Because of the possibilities of
`network delaysorfailures, the notification of an event may be delayed indefinitely
`and evenlost in the case of a distributed system.
`Indeed, there are times in a distributed system when the object of a notifica-
`tion may actively desire that the notification be delayed. In systems that allow
`object activation (such as is allowed by Java Remote Method Invocation (RMD) in
`the Java Development Kit, version 1.2, commonly called JDK1.2), an object might
`wish to be able to find out whether an event occurred butnot wantthat notification
`to cause an activation of the objectif it is otherwise quiescent. In such cases, the
`object receiving the event might wish the notification to be delayed until the
`object requests notification delivery, or until the object has been activated for
`Central to the notion of a distributed notification is the ability to place a third-
`party object between the object that generates the notification and the party that
`ultimately wishes to receive the notification. Such third parties, which can be
`strung together in arbitrary ways, allow ways of offloading notifications from
`objects, implementing various delivery guarantees, storing of notifications until
`neededor desired by a recipient, and the filtering and rerouting of notifications. In
`4 distributed system in which full applications are made up of components assem-
`bled to produce an overall application, the third party may be more than a filter or
`storage spot for a notification; in such systemsit is possible that the third party is
`the final intended destination of the notification.
`
`some Other reason.
`
`EV.1.2 Goals and Requirements
`
`
`
`riclilielasi
`
`The requirements ofthis set of interfaces are to:
`@ Specify an interface that can be used to send a notification ofthe occurrence
`@ Specify the information that must be contained in such a notification
`
`of the event
`
`
`
`169
`
`169
`
`

`

`
`
`
`
`
`
`
`
`THE JINI DISTRIB UTED EVENT SPECIFICATION
`
`|
`
`In addition, the fact that the interfaces are designed to be used by objects in
`different virtual machines, perhaps separated by a network, imposes other require-
`ments, including:
`# Allowing various degrees of assurance on delivery of a notification
`Support for different policies of scheduling notification
`Explicitly allowing the interposition of objects that will collect, hold, filter,
`and forward notifications
`
`
`
` RtATR
`
`
`
`Notice that there is no requirement for a single interface that can be used to
`register interest in a particular kind of event. Given the wide variety of kinds of
`events, the way in which interest in such events can be indicated may vary from
`object to object. This documentwill talk about a modelthat lies behind the sys-
`tem’s notion of such a registration, but the interfaces that are used to accomplish
`such a registration are not open to general description.
`
`EV.1.3. Dependencies
`
`This documentrelies on the following other specifications:
`
`@ Java Remote Method Invocation Specification
`
`@ Jini Distributed Leasing Specification
`
`
`
`
`170
`
`170
`
`

`

`
`
`EV.2 The Basic Interfaces
`
`
`
`159
`
`
`
`‘LD basic interfaces you are aboutto see define a protocol that can be used by
`one object to register interest in a kind of state change in another object, and to
`receive a notification of an occurrence ofthat kind of state change, either directly
`or through somethird-party, that is specified by the object at the timeof registra-
`tion. The protocol is meant to be as simple as possible. No attemptis madeto indi-
`cate the reliability or the timeliness of the notifications; such guarantees are not
`part of the protocol but instead are part of the implementation of the various
`objects involved.
`In particular, the purpose of these interfacesis:
`
`@ To show the information needed in any method that allows registration of
`interest in the occurrence of a kind of event in an object
`« To provide an example ofan interface that allows the registration of interest
`in such events
`
`@ To specify an interface that can be used to send a notification of the occur-
`rence of the event
`
`Implicit in the eventregistration and notification is the idea that events can be
`classified into kinds. Registration of interest indicates the kind of event that is of
`interest, while a notification indicates that an instance of that kind of event has
`occurred.
`
`EV.2.1 Entities Involved
`
`Anevent is something that happens in an object, corresponding to some change in
`the abstract state of the object. Events are abstract occurrencesthat are not directly
`observed outside of an object, and might not correspond to a changein the actual
`state of the object that advertises the ability to register interest in the event. How-
`ever, an object may choose to export an identification of a kind of event and allow
`other objects to indicate interest in the occurrence of events of that kind; this indi-
`
`
`
`j144:
`
`
`
`171
`
`171
`
`

`

`
`
`160
`
`ENTITIES INVOLVED
`
`cates that the abstract state of the object includes the notion of this state changing.
`The information concerning what kinds of events occur within an object can be
`exported in a numberof ways, including identifiers for the various events or meth-
`ods allowing registration of interest in that kind of event.
`An object is responsible for identifying the kinds of events that can occur
`within that object, allowing other objects to register interest in the occurrence of
`such events, and generating RemoteEvent objects that are sent as notifications to
`the objects that have registered interest when such events occur.
`Registration of interest is not temporally open ended butis limited to a given
`duration using the notion of a lease. Full specification of the way in whichleasing
`is used is contained in the Jini Distributed Leasing Specification.
`The basic, concrete objects involved in a distributed event system are:
`
`The objectthat registers interest in an event
`@ The object in which an event occurs (referred to as the event generator)
`Therecipient of event notifications (referred to as a remote eventlistener)
`
`An event generatoris an object that has some kinds of abstract state changes
`that might be ofinterest to other objects and allows other objects to register inter-
`est in those events. This is the object that will generate notifications when events
`of this kind occur, sending those notifications to the event listeners that were indi-
`cated as targets in the calls that registered interest in that kind of event.
`A remote event listener is an object that is interested in the occurrence of
`some kinds of events in some other object. The major function of a remote event
`listener is to receive notifications of the occurrence of an event in some other
`object (or set of o