!

DISTRIBUTED DISTRIBUTED OBJECTS AND

SYSTEMS REMOTE INVOCATION
CONCEPTS AND DESIGN
5.1 Introduction
5.2 Communication between distributed objects
Third edition
5.3 Remote procedure call
5A Events and notifications
GEORGE COULOURIS 5.5 Java RM I case study
Queen Mary and Westfield College, University of London 5.6 Summary
and Cambridge Univ~rsity
In this chapter we introduce communication between distributed objects by means of
JEAN DOLLIMORE remote method invocation (RMI). Objects that can receive remote method invocations are
Queen Mary and Westfield College, University of London
called remote objects and they implement a remote interiac8. Due to the possibility of
independent failure of invoker and invoked objects, RMls have different semantics from
local caBs. They can be made to look very similar to local invocations, but total
TIM KINDBERG transparency is not necessarily desirable. The code for marshalling and unmarshalHng
arguments and sending request and reply messages can be generated automatically by an
Hewlett-Packard Laboratories, Palo Alto
interface compiler from the definition of the remote interface.
Remote procedure call is to RMI as procedure call is to object invocation. It is
QA described briefly and illustrated by a case study of Sun RPC.
76 Distributed event-based systems allow objects to subscribe to events occurring at
.9 remote objects of interest and in turn to receive notifications when such events occur.
Events and notifications provide a way for heterogeneous objects to communicate with
.05 one another asynchronously. The Jini distributed event specification is presented as a
C68 case study.
The use of RMI is illustrated in a case study of Java RMI.
2001 ndon. '.ew York· Boston. San francisco. Toronlo Chapter 17 contains a case study on CORBA that includes CORBA RMI and the
'9apore • Hong Kong. Seoul. Taipei. New Delhi
159277 • Mexico City. Ams!erdam • Munich· Paris' Milan
CORBA Event Service .
ULL

165
166 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
5.1 Introduction
This chapter is concerned \'vith programming models for distributed applications - that
is. those applications that are composed of cooperating programs running in sewral
different processes. Such programs need to be able to invoke operations in other
processes. often running in different computers. To achieve this. some familiar
programming models have been extended to apply to distributed programs:
The earliest and perhaps the best~kno\Vn of these was the extension of the
conventional procedure call model to the remOfe procedure call modeL \\-hich
allows client programs to call procedures in server programs running in separate
processes and generally in different computers from the client.
~tore recently_ the object-based programming model has been extended to allow
objects in different processes 10 communicate with one another by mean:'> of
remote method il1mcari01/ (RMI). R\11 is an extension of local method invocation
that allows an object living in one process 10 in\'oke the methods of an object
li\'ing in another process.
The event-based programming model allO\vs objecb to receive notification of the
e\'ents at other objects in which they have registered il1lerest. This model has been
extended to allow distributed e\'ent-based programs to be written.
:\ote that we use the term 'RMr to refer 10 remote method invocation in a generic way
- this should not be confused \1.'ith particular examples of remote method invocation
such a.s Java RMI. \1ost curren! distribured systems software is written in object-
oriented languages. and RPC can be understood in relation to RML Therefore this
chapter concentrates on the RMI and CH:mt paradigms. each of \vhich applies to
distributed objects. Communication bet\\ een distributed objects is introduced in Section
5.2. followed by a discllssion of the des.ign and implementation of RML A Ja\'a R\1I
ca:,e smdy is given in Section 5.5. RPC is discussed in the context of a case study ot Sun
RPC in Section 5.3. Events and distribured notifications are discussed in Section .:z..+. A
further case study on CORSA is gi\"en in Chapter 17.
MiddJeware 0 Software that provide" a programming model above the basic building
block:;. of processes and message pas~ing is called middle"·are. The middlc\';arc layer
uses protocols based on messages he[ween proces"e.', 10 provick its higher-k\"(~l
ab'-.u3.ctions such as remote invocation.', and events. as illustrated in Figure :'i. 1. For
cX3.mp1e. the remote method in\"ocation abstraction i5 ba<.,ed on the requc$t-repJy
protocol discussed in Section 4..+.
..\n important aspect of middle\\ are is the pro\"ision of location transpMcn·.::- and
inckpendence from the details of communication protocols. operating system~ and
computer hardware. Some forms of middkware allow the separate component.; w bc
\',rinen in different programming language".
Location transparency: In RPC. the client that calls a proCedure cannot tell whether the
proc~dure runs in the same process or in a different proces". possibly on a different
computer. :\"or does the client need to know the location of the server. Similarly. in R\lI
the object making the invocation cannot tell whether the object it in\"okes is local IX not
and docs not need to kno\v its location ....\150 in dbtribuwd e\'erlt-based program~. the
SECTION 5.1 INTRODUCTION 167
Figure 5.1 Middlel'l3re layer
Applications
RM!, RPC and events
Middleware
Request reply protocol layers
External data representation
Operating System
ohject~ generating e\'ents and the obj~cts that recei\"{~ notifications of those events need
not be aware of one an others . locations.
Communication protocols: The protocols that ~upport the middk\\'are abstractions are
independent of the underlying transpon prOtocols. For example. the request-reply
protocol can lx: implemented o\"er either CDP or TCP.
Computer hardware: T\\:o agreed qandards for external data representation are
described in Section 4.J. These are u~ed when marshalling and unmarshalling rne';sages.
The~ hide the differences due to hard\\'arc architectures. such ao: byte ordering.
Operating systems: The highcr-!c"cl abstractions provided by' the middlcware layer are
independent of the underlying operating ~yq"m~.
Use of several programming languages. Some midd!c\vare is designed to allo\\
distributed applications to usc more than 0ne programming language. In particular.
CORSA (sec Chapter 17) allov,:s clients \willen in one languagc to invoke methods in
objects that li\':: in sel'Ver programs \\Tlucn in another language. This is achie\",;:d D::
using an ilJ{cr!(u'e defiIJiiio/l langu(;?(' or IDL t() define interfaces. JDLs are discllssed in
the nc\! section.
5.1.1 Interfaces
?-.Io,< modern programming languages pro\'idc J means of organizing a program ao: a :--Cl
of modulc" thal can communicate \'- ith one ;~n('Iher. Communication betWeen moduk~
can be by mcan~ of procedure call~ bet\\een m<..x1uks or by direct acc,;:ss to the \'ariable~
in anOther module. In order to comfol the f'(\~~ible interactions between modules. an
e:\piicll iIliCr'(i("(' is defined for each [l1oduk. The interface of a module specific:-- the
proccJurc:-- and ,he \"ariables that can he 2~'cc"ed from other modules. :'vlodulc:-- are
implcmcmed -0 a~ to hidc all the ini"ormmi('n ..o[->oul them e;.;ceptthat which is m'aiiabk
thrc'ufh ito: imerfacc. So long a" ib ;!1lcrfacc ~e;"nains the same. the implementation 111<1;-
b:: ("hanged \~ iit,out afrecting the u~::rs of the ::1Odu1c.
Interiaces in distributed systems 0 In a Ji:--tribulCd program. the modules can run in
separclle procc~~c'" It is not po:'-sihle for ,! mexlule running in one process to accc,,, thc
\"ariubk" in a module in another pr(lCC~~. Thcrd"ore. the interface of a module that i"
intended for RPC or R\1! cannot specify direct access to variables. i\ote that CORBA
IDL intcrface~ can ~peciry atlributc:--. which ,cems to break this rule. Ho\\·c\·er. thl:'

168 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
attributes are not accessed directly but by means of some getter and setter procedures
added automatically to the interface.
The parameter-passing mechanisms. for example call by value and cali by'
reference. used in local procedure call are nOl suitable when the caller and procedure are
in different processes. The specification of a procedure or method in the interface of a
module in a distributed program describes the parameters as inpur or oWput or
sometimes both. Input parameters are passed to the remote module by sending the values
of the arguments in the request message and then supplying them as arguments to the
operation to be executed in the server. Ourput parameters are returned in the reply
message and are used as the result of the cal! or to replace the values of the
corresponding variables in the calling enyironment. When a parameter is used for both
input and output the value must be transmitted in both the request and reply messages"
Another difference bet\veen local and remote modules is that pointcr~ in one
process are not valid in another remote one. Therefore, pointers cannot be passed as
arguments or returned as results of calls to remote modules.
The next tviO paragraphs discuss the interfaces used in the original client~se"'\,;r
model for RPC and in the distribllled object model for RMI:
Service interfaces: In the client-sen·er model. each server pro\"ides a set of procedure<..
that are available for use by clients. For example. a file server would provide procedures
for reading and writing files. The term scrl'ice infelface is used to refer to the
specification of the procedures offered b: a server. defining the types of the input and
output arguments of each of the procedurc~.
Remote interfaces: In the distributed object model. a rClI10rc intel/ace :;pccific~ the
methods of an object that are available fOf in\"ocalion by objects in other proce~'-e~,
defining the types of the input and outpUi arguments of each of them. Ho\\·e\·er. the big
difference is that the methods in remote interfaces can pas~ objects as argument~ and
results of methods, In addition, referencc3 iO remote objects may also be pa~scd - tnc"c
should not be confused with pointers, which refer to specific memory locations. (Section
4.3.3 describes the contents of remote obje.:t references.)
:\"either service interfaces nor remote inte.f:::ces may specify direct access to variable;;.
In the latter case, this prohibits direct acc<.',,:' to the instance \"ariables of an objec!.
Interface definition languages 0 An R\H mechanism can be integrated with a paflicular
programming language if it include~ an adequate notation for defining interface".
allowing input and output parameter:; 1O lX' mapped onto the language's normai u'-e of
parameters. Java RMI is an example in \\ hich an RMI mechanism has been added h' an
object-oriented programming language. This approach is useful when all the pan~ eli a
distributed application can be written in the same language. It is also conn"::nicnt becJ.u~e
it allows the programmer to use a singie ianguage for local and remote inwlCation.
However. many existing useful ~ef\ ices arc written in C++ and other languzges.
It would be beneficial to allow program:, \\Titten in a yariety of languages. including
Jaya, to access them remotely. [melface dl',/illiriol1ianguages (or IDLs) are designed to
allow objects implemented in different languages to invoke one another. An IDL
provides a notation for defining jnterfaee~ in which each of the parameter" of a method
may be described as for input or outpUT in addition to ha\'ing iIS type specified.
SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 169
Figure 5.2 CORBA IDL example
Illn.fite PerSOl1.idl
struct Person r
string name:
string place:
tonK year:
} :
inrelface PersonLisl r
readonly atlri/Jwe string listnamc:
void addPerson(in Person p):
void getPerson(in srring name. our Persall p):
long l111mber( j:
}.
Figure 5.2 shO\vs a simple example of CORBA 1DL The Persoll structure is the
same as thc one used to illustrate mar"halling in Section -L~.l. The interface named
PcrsollLisr specifics the methods available for R~·f1 in a remote object that implements
that interface. For example, the method addPersol1 specifies its argument as ill, meaning
that it is an inpul argument: and the method gcrPersoll that retriews an instance of
Person by name specifie:- its ~econd argument as out. meaning that it is an Oili{)lIf
argument. Our case :o;tudies include CORB.-\ IDL as an example of an lDL for R\ll I in
Chapler 17) and Sun XDR as an lDL for RPC.
Other examples include the interface definition language for the RPC system in
the OSFs Distributed Computing Em'ironment (DCE) [OSF 1997J, which lI~es C
language syntax and is called lDL: and DeOM IDL which is hased on DeE lDL [Box
1998] and is used in Microsoft's Distributed Component Object Model.
5.2 Communication between distributed objects
The object-based model for a distributed s;. stem introduced in Chapter I extend" the
model supported b:y object-oriented programming language~ to make it appl: iO
distributed objeet:o;. This section addre,,~e<. communication between distributed objects
hy means of RMJ. The material is presen1<.'d under the 1'0110\\·ing headings:
The o/~iecr lIIode!: A brief review of the re]cyam as-peel::- of the object modeL ~lllwbk
for the reader with a ba~ic knowledge of an ohject-oriented progromming langu:,gc,
for example Java or C++.
Dixtri/tUlcd ohjecrs: A presentation of objeu-based di~tributed system:o;, \, hich
argues that the object model is vcry 3prropriatc for di~tribllted ~ystcm".
The disfI"ihuwd o/~iect mode!: A di~cu~~ion of the extensions to the objecl l110del
necessary for it to support distrihuted c'bject:'-.

170 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
Design issues: A set of arguments about the design alternatives:
1. Local invocations are ex.ecuted exactly once. but what suitable semantics is
possible for remote invocations?
2. How can RMI semantics be made similar to those of local method invocation
and what differences cannot be eliminated?
lmplemenrarion: An explanation as to how a layer of middleware above the request-
reply protocol may be designed to support RMI between application-level distributed
objects.
Distributed garbage collection: A presentation of an algorithm for distributed
garbage collection that is suitable for use with the RMI implementation.
5.2.1 The object model
An object-oriented program. for example in Java or C++. consists of a collection of
interacting objects. each of which consists of a set of data and a set of methods. An
object communicates with other objects by invoking their methods. generally passing
arguments and receiving results. Objects can encapsulate their data and the code of their
methods. Some languages. for example Java and C++. allow programmers 10 define
object"; \\ho;'.c in.<.tance variables can be accessed directly. But for use in a distributed
object syqcm. an object's data should be accessible only via its methods.
Object references 0 Objects can be accessed via object references. For example. in Java.
a variable that appears to hold an object actually holds a reference to that object. To
invoke a method in an object. the object reference and method name are gi\·en. together
with any necessary arguments. The object whose method is invoked is sometimes called
the target and sometimes the receiver. Object references are first-class values. meaning
that they may. for example. be assigned to variables. passed as argumenb and returned
as results \)f melhods.
Interfaces: .\n interface provides a definition of the signatures of a set of methods (that
is. the tyf'C'~ of their arguments. return values and exceptions) without specifying their
implememation. An object \\."ill provide a particular interface if its class contains code
that impkmcnts the methods of that interface. In Java, a class may implement several
interface::.. and the methods of an interface may be implemented by any class. An
interface ",]:'0 defines a type that can be used to declare the type of \'ariable::, or of the
parametef~ and return values of methods. Note that interfaces do not ha\'e constructors.
Actions ~ Action in an object-oriented program is initiated by an object invoking a
method I;: anOther object. An invocation can include additional information (arguments)
needed to carry out the method. The receiver executes the appropriate method and then
returns control 10 the invoking object. sometimes supplying a result. An in\'ocation of a
method can ha\'e tWO effects:
1. the 'tate of the recei\'er may be changed. and
2. funher in\'ocations on methods in other objects may take place.
SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 171
As an invocation can lead to further invocations of methods in other objects. an action
is a chain of related method invocations. each of \.... hich eventually returns. This
explanation does not take account of exceptions.
Exceptions 0 Programs can encounter many sorts of errors and unexpected conditions
of varying seriousness. During the execution of a method. many different problems rna;
be discovered: for example. inconsistent values in the object's variables. or failure in
attempts to read or write to files or network sockets. When programmers need ro insen
tests in their code to deal with all possible unusual or erroneous cases. this detracb from
the clarity of the normal case. Exceptions provide a clean \\'ay to deal \>, ith error
conditions without complicating the code. In addition. each method heading explicitl:
lists as exceptions the error conditions it might encounter. allowing users of {he method
to deal with them. A block of code may be defined to rhro\\' an exception whenen:-r
particular unexpected conditions or errors arise. This means that control passes to
another block of code that catches the exception. Control doe:.- not return 10 thi:' plaCe
where the exception was thrown.
Garbage collection 0 It is necessary to provide a means of freeing the space (x:cupied b:
objects when they are no longer needed. A language. for example Java. that can detect
automatically when an object is no longer accessible recovers the space and makes it
available for allocation to other objects. This process is called garbage col1ecuOI? When
a language (for example C++) does not support garbage collection. the programmer ha~
to cope with the freeing of space allocated to objects. This can be a major ,ource of
errors.
5.2.2 Distributed objects
The :.-tate of an object con~i~ts of the \'alue~ of its instance \·ariabks. In the obje-:l-ba~ed
paradigm the state of a program is partitioned into separate raftS, each of __,hich i~
associated with an object. Since object-based program'> are logically partill~'ned. the
physical distribution of objects into different proces:.-e<, or computers in a j,:'triburcd
system is a natural extension.
Distributed object <,ystems may adopt the clienHern'r ar.:hitecture. In :hi" ca"e.
ohjeCI:-- are managed b: servers and their clients in\'oke their n,<,:thods u"jr:f femott
method inyocation.ln R\fI. the client's request to inVOKe a me:hod of an 0bjc~t is :,em
in a message 10 the sen'er managing the object. The imOc2tion is cameJ out b:
executing a method of the object at the sen'er and the re;;ult i~ r2tumed to ,he .:l1ent in
another message. To allow for chains of related invocatiom. 0hjects in ~;;;-, er:, ;:ire
allowed to become cli.::nt~ of objects in mhe, serycrs.
DiStributed objecb can assume the other archiwclllr:l1 ",('deb dc<:-,bed
Chapter 1. For example. objects call be rcpli.::ated in order to obt:!in the usu2.1 b-2r:dit, .:,f
fault tolerance and enhanced performance. and objccb can k rliifrared \\ iih .:. '. ic\\, "~
enhancing their performance and availabilit:.
Having client and "erver objects in different proccsse:, enforces en':~~'Lllail(':'
That i~, the state of an objcct can be accc<,sed only b~ Ihe mtthc,(j:-. of lhe obje.:: \\ hieh
means that it is not pos~ible for unauthorized methods to aCI on til.:: state. F(1r c\;::mpk.
the possibili!:y of concurrent RMls from objects in different wmputers impl1,,"~ lhal :,r1
object may be accessed concurrently. Therefore. the po:--sibilit:- ell c()nflictin; ,,:,x·c,,,.>
172 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 173

Figure 5.3 Remote and local method invocations Figure 5.4 A remote object and its remote interiace

remO~~~?bL~9!
oG.?L-.:=: c
\'
\
¥,~yifiV"ocation ;V~Cal (n~,
If"' ____ local invocallU~ ~ Data

- mi \
remote

invoca!tmr--'0 0
(
"
.•........".:.
\~-.-'".-".-'"
)
•\

......
illterf.aC'{

~3
.L~~.~ ----,
implementation

\ '-
m4 V.oJ,
m5--- .~

~.~~ methO~.~.__ ,~ m6
J.
arises. However. the faci that the data of an object is accessed only by its own methods
a1!o\vs objects to proyide methods for protecting themseh'cs against incorrect accesses.
For exmnple. they may use synchronization primitives such as condition variables to The following paragraph~ discuss remOie object references. remote interfaces and other
protect access to their instance variables. aspects of the distributed object model.
Another ad\"antage of treating the shared state of a distributed program as a Remote object references 0 The notioD of object reference is extended to allow any
collection of objects is that an object may be accessed \'ia RMI or it may be copied into object that can receive an R\-H to haye a remote object reference. A remote object
a local cache and accessed directly provided that the class implementation is available reference is an identifier that can be u"ed throughout a distributed sy.;;tem to refer to a
locally. particular unique remote objecLlts representation. \,'hich is generally different from that
The fact that objects are accessed only via their methods gives another adyantage of local object references. is discus:-,ed in the Section ...J.":'.3. Remote object references are
for heterogeneous systems in that different data formats may be used at different sites ~ analogous to local ones in that:
these formats will be unnoticed by clients that use R\H to access the methods of the I. the remotc object to recci\"e a remote method im'ocation is specified as a remote
objects. object reference: and
2. remote object rcrerence~ 111[(; k passed a~ argumems and results of remme
5.2.3 The distributed object model method invocations.

This section discus:-,es extensions to the object model to make it applicable to distributed
objects. Each process contains a collection of object:-,. some of which can receive both
local and remote imocations. whereas the other objects can receive only local
invocations. as shown in Figure 5.3. Method inyocations between objects in different
processes. \vhether in the same computer or not. are known as remOTe method
im·oC(uiol1s. Method inyocations between objects in the same process are local method
invocations.
We refer to objects that can receive remote imocations as remote objeos. In
Figure 5.3. the objects Band F are remote object',. All objects can recei\'e local
invocations. although they can receive them only from Other objects that hold references
to them. For example. object C must have a reference to object E so that it can im'oke
one of its methods. The following 1\,'0 fundamental concepts are at the heart of the
distributed object model:
Remme ()/~iecr rej"e}"c!1("(,: Other objects can invoke the methods of J remote object
if they haye acce:-.:-. to its remote object referellce. For example. a remote object
reference for B in Figure 5.3 must be available to A.
Rel/Wle intel.ir.lce: Eyery remote object has a remole imC/face that specifies which of
it~ methods can be in\'oKed remotely. For example. (he objects Band F must havc
remote interfaces.
Remote interfaces 0 The cbss of a remote object implements the methods of its remote
interface, for example a:-, public inSl2nce melhod~ in JaYa. Objects in other processes can
in\"oke only lhe mdhods that belong ,0
it'; remote interfacc. as Sh0\\D in Figure SA.
Local objects can innlke the method:- in lhe rcrnote interface as well ;J.:' other method~
implemented by a remote ohject. :-':ot<:" ,h.lt remOle interfaces. like alli"terfaccs. do not
have constructors.
The CORBA system proyidc'- an interface definition languag;;".' ,,!DL). which i~
lIs.::d for defining remote interfaces. Sec Figure 5.':' for an example of 3. ;emote interface
defined in CORBA !Dt. The classe~ (,i remote objects and the cli.::n: programs may be
implemented in any language such 2.' C++ or Ja\":l for which an IDL compikr i~
anlilable. CORBA diems need not u,e lhe same language as the remNe object in ()rdcr
to inn)ke its methods remotely.
In Jay<\ R\·1L remote interface, are defined in the same W2: a:- <lny other Ja\'a
interface. They acquire their abdit: ,,' "r-c rcmote E1ierfaces hy extending an interface
named Remme. Both CORBA lDL f Section I :.2.3) and Jay.! ,upport muhipk
inheritance of interfaces. That i:-.. an ;THerfacc i~ ajJ{)\'.ed to extend "rie or more other
interfaces.
Actions in a distributed object system A:-:. in lne non~distributed C3:'C. an action i"
initiatcd by a method ioyocation. which may re:-,uil in further in\'ocation,;; on me!hod:- in
other objects. But in the di:--.tributed ca:--.e. the Ohj-::C1S invoh'ed in a chain of related
174 CHAPTER 5 DISTRIBUTED OBJECTS ANO REMOTE INVOCATION
invocations may be located in different processes or different computers. When an
invocation crosses the boundary of a process or computer. RMI is used. and [he remote
reference of the object must be a\"ailable to make the RMI possible. In Figure 5.3. the
object A needs to hold a fcmQ[e object reference to object B. Remote object references
may be obtained as the results of remote method invocations. For example. object A in
Figure 5.3 might obtain a remote reference to object F from object B.
Garbage collection in a distributed-object system 0 If a language, for example Java.
supports garbage collection. then any associated RMI system should allow garbage
collection of remote objects. Distributed garbage collection is generally achieved by
cooperation between the existing local garbage collector and an added module that
carries out a form of distributed garbage collection, usually based on reference counting.
Section 5.2.6 describes such a scheme in detail.
Exceptions 0 Any remote invocation may fail for reasons related to the invoked object
being in a different process or computer from the invoker. For example. the process
containing the remote object may have crashed or may bc too busy to reply, or tho.':
im'ocation or result message may be lost. Therefore, remote method invocation should
be able to raise exceptions such as timeouts that are due to distribution as \vell as those
raised during the execution of the method invoked. Examples of the latter are an attempt
to read beyond the end of a file. or to access a file \vithout the correct permissions,
CORBA JDL provides a notation for ~pecifying application-level exceptions, and
the underlying system generates standard exceptions when errors due to distribution
occur. CORBA client programs need to be able to handle exceptions. For example. a
C++ client program \vill usc the exception mechanisms in C++.
5.2.4 Design Issues for RMI
The pre\'ious section suggested that R:-'lI is a natural extension of local method
im·ocation. In this section, we discuss two design issues that arise in making this
extension:
,Although local invocations are executed exactly once, this cannot always be the
case for remote method im'ocations, The alternatives are discussed.
The level of transparenc)-'" that is desirable for RMI.
In the remainder of Section 5.2. \\'e refer to the processes that host remote objects a:,
sen'ers and the processes that host their invokers as clients. Servers can also be clients.
RMI invocation semantics 0 Request-reply protocols were discussed in Section 4.4-
wh.::re we shO\ved that doOpaariol1 can be implemented in different ways to pro\'ide
different deliyery guarantees. The main choices are:
Refry request message>: whether to retransmit the request message until either a reply
i::-. recei\'ed or the server is a~sumed to haye failed.
Dup/icarc jiltering: v,:hen retransmissions arc used. whether to filter out duplicate
requests at the server.
Retransmissioll (!i'results: whether to keep a history of result messages to enable lost
results to be retransmitted without re-executing the operations at the ;;eryer.
SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 175
Figure 5.5 Invocation semantics
Fault roierance measures llil"ocario!1
sem(ll1.ics
Retransmit reqllcst Duplicafe Re~execille procedure
message filtering or retransmit reply
No Not applicable Not applicable .\fayhe
Yes No Rc-execute procedure Ar-leasr-once
Yes Yes Retransmit reply Ai-1II0SI~once
Combinations of these chojce~ lead to a variety of possible semantics for the reliabilil:
of remote invocations as seen by the invoker. Figure 5.5 shows the choice~ of interest.
with corresponding names for the im'ocation semantics tbat they produce. \"ote that for
local method invocations. the ~clllantics <Ire exactly once. meaning that e\er: method i::;
executed exactly once. The inn)Cation semantics are defined as follow::;:
Maybe invocation semantics: With mayhe invocation semantics, the remOt2 method ma:
be executed once or not at all. \-1aybe semantics arises when none of the r'3.ult tolerance
measures is applied. This can :,uffer from the following types of failure:
omission failures if the inyocation or result message is lost:
crash failures when the sen'er containing the remote object fails.
If the result message has not been received after a timeout and there are no retries, it i::;
uncertain whether the method has been executed. If the invocation mes~.ag<'! \;;as lost.
then the method will not haw been executed. On the other hand, the method may ha,'e
been executed and the result message lost. A crash failure may' occur ei,her before or
after the method i:'o executed. :-'1orcover. in an asynchronous system, ,he result Oi:'
executing the method may ilrriye after the timeout. Mayhe semantics is. usdul onl: for
applications in \vhich occasional failed invocations are acceptable.
At-least-once invocation semantics: With af-feaST-onCe> invocation semanth:>. the invoker
receives either a result. in which case the invoker knows that the method \1, as executed
at least once, or an exception informing it that no result was recei\·ed. A:-{c{1.>i·oncc
im'ocation semantics can be achie\'ed by the retransmission of requeq m~,.;ages. ,'.. hici'.
masks the omi~sion failure" of the invocation or result rne:,sage. J,:-!COSH'/:CI.'
invocation semantic:, can :'outler from the following type" of failure:
crash failures when the server containing the remote object fails:
arbitrary failures. In ca:,cs when the invocation message is retr3.n~mincd. the
remote object may recei\'e it and execute the method more than on.:.::. pos-"ibi:
causing \v"fong values to be stored or returned.
176 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 177

Chapter 4 defines an idempotent operarion as one that can be perfomlcd repeatedly with Figure 5.6 The role of proxy and skeleton in remote method invocation
the same effect as if it had been performed exactly oncc. Non-idempotent operations can
have the wrong effect if they are performed more than oncc. For example. an operation
to increase a bank balance by S 10 should be performed only once: jf it Wefe to be Ldi~~n~t~·~ server
/"'s'keieton~
remote
repeated, the balance would grow and gro\"'~ If the objects in a server can be designed object 8
! . object
~ .... --
A proxy
r"·~.
for B.,.....", \. Request
_~._ __ ,~""'. '& dispatcher
so that all of the methods in their remote interfaces are idempotent operations. then at-
\!or 8's class
least-once call semantics may be acceptable.
\ ,., . \._) '~.-

At-most-once invocation semantics: \Vith at-mast-once invocation semantics. the ;V~ Reply ',--.j I

invoker receives either a result in which case the invoker knows that the method was '... : "-'-

executed exactly once, or an exception informing it that no result was received. in \vhich
case the method will have been executed either once or not at all. At-mast-ol1ce
invocation semantics can be achieved by using ail of the fault tolerance measures. As in
the previous case. the use of retries masks any omission failures of the invocation ()f
result messages. The additional fault tolerance measures pre\'ent arbitrary failures by
ensuring that for each RMI a method is never executed more than once. In bOlh J,l"a
RMI and COREA. the invocation semantics is aT-mOST-Ollce. but CORB:.'>, allo,,"s mayhe
semantics to be requested for methods that do not return results. Sun RPC provic\es at-
least-once call semantics.
Transparency 0 The originators of RPC Birrell and Nelson [198-1.J. aimed to make
remote procedure calls as much like local procedure calls as possible. with no distinction
in syntax bet\\een a local and a remote procedure call. All the necessary calls to
marshalling and message-passing proc<::'dures \\"t;~re hidden from the programmer making
the call. Although request me%ages are retransmitted after a timeoul. thi~ is transparent
to the caller - to make the semantic,:; of remote procedure call" like that of local
procedure calls. This notion of transparency has been extended to app).'- to distributed
objects. but it in\'olves hiding not only marshalling and message pa'<':'-ing but abo the
task of locating and contacting a remme object. As an example. Ja\'u R\ll makes remote
method in\'ocations very like local ones by allowing them to use the :'-3me .'yntax.
However. remote invocation:,- arc more ndnerable to failure than \()cal ones. since
they involve a network. another compmer and another process. Whichc\ cr of the abo\'e
invocation semantics is chosen. thcre i~ always the chance that no rc:,ult \,'i11 be received
and in the case of failure. it is impos"ible to distinguish between failure of the network
and of the remme server process. This requires that objects making r<,mote in\"ocations
be able to reCO\'er from such situations.
The latency of a remote invocation is se\'eral orders of magnitude greater than that
of a iocal one. This suggests that programs that make usc of remote in\'ocation" need to
be able to take this factor into account. perhap., by minimizing remote inter:'H.:tion<;. The
designers of Argus [Liskov and Schdler 1982] suggested that a calkr ... hould be able to
aboft a remote procedure call that j<. taking too long in sllch a \\"01: then it h:'l~ no effect
on the -"erver. To allow this. the ."er'er would need to be able to r,;-,... tOre thing., to ho\\
they were before the procedure wa" calkd. Thc;..c i"sues arc discu,,:-.cJ in Chapter 12.
Waldo ('t al. [1994] say that [he difference between local Jnd remote objects
should be expres.sed at the remote interface. to allow object.' to react in a c{lnsi."'-lenl wa.y
to possible partial failures. Other "ystems went further than thi" b:- arguing that the
syntax of a remote call should be different from that of a local call: in the ca~e of Argus.
the language was extended to make remote operations explicit to the programmer.
l':"-:=/~
Remote Communication Communication Remote reference
module
reference module module module
The choice as to whether remote invocations <.;hould be transparent is abo
available to the designers of IDLs. For example, in CORBA. a remOle in\·oC3.1ion throws
an exception when the client is unable to communicate \>':i[h a remote object. This
requires that the client program handle such exceptions. allowing it to deal \\'ith such
failures. An IDL can also provide a facility for specifying the call semanlic~ of a method.
This can help the designer of the remote object - for example. if at-kast~once call
semantics is chosen to avoid {he overheads of at-most-once. the operation..; of the object
are designed to be idempotent.
The current consensus seems to be that remote invocations ~houki he made
transparent in the sense that the syntax of a remote invocation j" the same 3:' tn,lt of a
local invocation. but thaI the difference between local and remote object" "hould he
expressed in their interfaces. In the case of Java R!\·1L remote object:-. can be
distinguished by the fact that they implement the Rem()fe intcrfacT and throw
RC!I1oreExceptiolls. lmplementors of a remote object whose interface i" specified in an
IDL are also aware of the difference. The knO\v1edge that an object is imended to be
accessed by remote invocation has another implication for its de"igner: it ~houid be able
to keep its state consistent in the presence of concurrent accesse~ from ll1uliiple clients.
52.5 Implementation of RMI
Several separate object::, and modules are involved in achie\ in,g ;1 remote method
im·ocation. These are shO\>"n in Figure 5.6. in \vhich an application-!c\c! object A
invoke~ a method in a remote application-level object B for \\ hich it h(""tlJ~ ~, f<,mote
objeCt reference. This section discusses the roles of each of the componems ... howl1 in
that figure. dealing first with {he communication and remote rderence nwduk> ~l!1d then
\\'ith the RMI software that rllns O\'er them.
The remainder of this ~ection deals with the follo\"ing rebtd wpic~: the
generation of proxies. the binding of names to their remote ot;.i<'CI re(cn.::nce". ,he
activation and passi\'ation of objects and the location of objech from thei.- ren1(,\e object
references.
Communication module 0 The t"'. o cooperating communication modllk~ c~,rr~ out the
request-reply protocol. which transmits requ!'s[ and reply messages bct\;.ecn c'lient and
ser\"l~r. The Contents of requeST and reply message." arc ShO\<;[l in Figu:c .1. j:-. The

178 CHAPTER 5 DISTRIBUTED OBJECTS ANO REMOTE INVOCATION
communication module uses only the first three items. which specify the message type,
its reques[/d and the remote reference of the object to be invoked. The merhodld and all
the marshalling and un marshalling is the concern of the RMI software discussed below.
The communication modules are together responsible for providing a specified
invocation semantics. for example at-most-once.
The communication module in the server selects the dispatcher for the class of the
object to be invoked. passing on its local reference. which it gets from the remote
reference module in return for the remote object identifier in the request mc-<;.sage. The
role of dispatcher is discussed under RMI software below.
Remote reference module 0 A remote reference module is responsible for translating
between local and remote object references and for creating remote object references.
To support its res.ponsibilities. the remote reference module in each process has a remote
objecr table that records the correspondence between local object references in that
process and remote object references (which are system-wide). The table includes:
An entry for all the remote objects held by the process. For example. in Figure 5.6.
the remote object B will be recorded in the table at the server.
An entry for each local proxy. For example. in Figure 5.6 the proxy for B will be
recorded in the table at the client.
The role of a proxy is discussed under RMI software below. The actions of the remote
reference module are as follo\\.'s:
When a remote object is to be passed as argument or result for the first time. the
remote reference module is asked to create a remote object reference. which it
adds to its table.
When a remote object reference arrives in a request or reply message. Ihe remote
reference module is asked for the corresponding local object reference. \vhich may
refer either to a proxy or to a remote object. In the case that the remote object
reference is not in the table. the RMI software creates a new proxy and asks the
remote reference module to add it to the table.
This module is called by components of the RMI softw8.re when they are marshailing
and un marshalling remote object references. For example. when a request message
arriyes. the table is used to find out which local object is to be invoked.
The RMI software 0 This consists of a layer of soft\,are between the application-leyel
objects- and the communication and remote reference modules. The roles of the
middle'xare objects shown in Figure 5.6 are as follo\,-::-:
Pro.':y: The role of a proxy is to make remote method in\"ocation tran~paren[ to
clients by behaving like a local object 10 the in\'oker: but instead of executing an
inyocation. it forwards it in a message to a remote object. It hides the detail:; of the
remote object reference. the marshalling of arguments. unmarshalling of resulls and
sending and receiving of messages from the clienL There is one proxy for euch
remote object for which a process holds a remme object referencc. The class of a
proxy implemcnts thc methods in the remote interface of the remotc object it
repre~cnts. This ensures that remote method im·ocations are suitable for the type of
the remote object. Howc\"er. thc proxy implements them quite differently. Each
SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 179
method of the proxy marshals a reference to the larger objec!. its own methodJd and
its arguments inlO a request message and sends it to the target. awaits the reply
message. un marshals it and returns the results [0 the lm·oker.
Dispatcher: A server has one dispatcher and skeleton for each class representing a
remote object. In our example. the scrWr has a dispatcher and skeleton for the class
of remote object B. The dispalCh<:r recei\·es the request message from the
communication module. It uses the lIu:thodld to select the appropriate method in the
skeleton. passing on the request me.;.sage. The dispatcher and proxy use the same
allocation of method/ds to the methoJ ... of the remme interface.
Skeleton: The class of a remote objc.:r has a skeicwil. which implements the methods
in the remote interface. They are implemented quite differently from the methods in
the remote objec!. A skeleton methed unmarshab the arguments in the reqllesr
message and invokes the correspondirJ.g method in the remote object. It \vaits for the
invocation to complete and then marshaj~ the result. t~"'gether \\-ith any exceptions. in
a reply message to the sending prox:· ~ method.
Remote object references arc marshaijcd in the form sho\\-n in Figure 4.10. which
includes information abom the remote i",-:'rface of to.:- :-emote object. for example the
the name of the remote interface or the class of Ih,;- ,~mot,;: object. This infonnation
enables the proxy class to be determine": >0 that a ne\, ;,rm:y may be created when it i::;
needed. For example. the proxy cJa~" n::.:::-:e may be gcne,:::!ed by appending "YTO.\""y" to
the name of the remote interface.
Generation of the classes for proxies, dispatchers and skeletons C· The da"ses for the
proxy. dispatcher and skeleton used in R:\H are gener::.ted automatically by an interface
compiler. For example. in the Orbix iIT:;,kmemation (,;' COREA, interfaces of remote
objects are defined in CORBA IDL. an': che interface '::0mpiler can be used to generate
Ihe classes for proxies. dispatchers ;}".: ~keletons in C----. For Ja\·a R)"H. the set of
methods offered by a remote object i~ ':erlned as a 12'-::: interface that is implemented
,,-ithin the class of {he remote object. n.~ Java R\11 .::ompiler generates the prox:.
dispatcher and skeleton classes from the .::bss of the re:TJ0t.:- Object.
Server and client programs 0 The ser, e: program ~-~""m;}in,<. the classes for the
dispatchcrs and skeleton". together wilr. ::,e impkme:;;J.:,on..:.. of the cla~ses of all of the
remote objects that il support~, The ;::.::e, are some ::nes called >er\-ant clas~es. In
addition. the sCr\'er program contains .::.:-. :-!:iriakmi(": ,ec(iOn (for example in a main
method in Java or C++). The illiti{l/;,:.~:i(ln secti0r1 ::; ;-esponsible for creating and
initializing at leaq one of the remote :':-'.;2"C:15 to be ;-:{'"cd hy the sen-er. Addition2.1
remote objects rna: be created in re"j:'(':--",: to requc'i~ ;·'om clients. The iniliafi:afion
:.-ection may al~o register some of ii, ~cm(){e obje~':- \, !lh a binder (see lhe nex,
p3r'lgraph). Generally. it will n::giSlcr one remc':O: ,:'bjccl. \\-h)Ch ..::an be u~ed 10
accc~s the re~l.
The clienl program will contain ::.'-' ,-'1a~"es 0;· .. .: proxies f('r all of the rcmOlC
objects that it will in\'oke. It can use a :--::--,.:;cr to look c.:;:-- ~em0tc object reference<..
Factory methods: \Ve notcd earlier ti',"" remote ob:c..::t interface:.- cannot include
COlhtructors. This means that remote ob,iccts cannot tv.> .::rcatcd by remote in\·ocation on
constructors. Remote objects are created Ci her in the II ;;;dli::'(ifiol1 section or in method~
 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
180
in a remote interface designed for that purpose. The termfaclor), method is sometimes
used to refer to a method that creates remote objects. and ajaclOry object is an object
with factory methods. Any remote object that needs to be abJe to create new remote
objects on demand for clients must provide methods in its remote interface for this
purpose. Such methods are called factory methods. although they are really just normal
methods.
The binder 0 Client programs generally require a means of obtaining a remote object
reference for at least one of the remote objects held by a server. For example. in Figure
5.3. object A would require a remote object reference for object B. A hinder in a
distributed system is a separate service that maintains a table containing mappings from
textual names to remote object references. It is used by servers to register their remote
objects by name and by clients to look them up. Chapter 17 contains a discussion of the
CORBA Naming Sen·ice. The Java binder. RMlregisu")!, is discussed briefly in the case
study on Java RMI in Section 5.5.
Server tnreads 0 v.,.'henever an object executes a remote invocation, that execution may
lead to further invocations of methods in other remote objects, which may take some
time to return. To avoid the execution of one remote invocation delaying the execution
of another. servers generally allocate a separate thread for the execution of each remote
invocation. When this is the case. the designer of the implementation of a remote object
must allow for the effects on its state of concurrent executions.
Activation of remote objects 0 Some applications require that information sUfvi\'e for
long periods of time. HO\vever. it is not practical for the objects representing such
information to be kept in running processes for unlimited periods. particularly since they
arc not necessarily in use all of the time. To avoid the potential waste of resources due
to running all of the servers that manage remote objects all of the time. {hc sern~rs can
be started whenever they are needed by clients. as is done for the standard set of TCP
services such as FTP. which are started on demand by a service called Inerd. Processes
that start server processes to host remote objects are called acrimrors for the following
reasons.
A remme object is described as auil"c when it is available for invocation within
a running process, \vhereas it is called pass!l'c if is not currently active but can be made
active. A passi\'e object consists of two parts:
I. the implementation of its method:;,: and
2. its state in the marshalled form.
ActiwItiOIl con:,ists of creating an acti\'e object from the corresponding passive object by
creating a Ilew instance of its class and initializing it:; instance variables from the :>lored
state. Passive objects can be actj\'ated on demand. for example when they need to be
in\'oked by other objects.
An acrimtor is responsible for:
Registering passive objects that are available for activation, which imoh'es
recording the names of servers against the URLs or file names of the
coo'esponding passive objects.
Starting named server processes and activating ren10te objects in them.
SECTION 5.2 COMMUNICATION BETWEEN DISTRIBUTED OBJECTS 181
Keeping track of the locations of the servers for remote objects that it has already
acti\·ated.
The CORBA case study describes its activator. which is called the implementation
repository. Java RMI uses Olle activator on each sen'er computer. \l,.'hich is responsible
for activating objects on that computer.
Persistent object stores 0 An object thaI is guaranteed to live between activations of
processes is called a persisrenr object. Persistent objects are generally managed by
persistent object stores \vhlch store their state in a marshalled form on disk. Examples
include the CORBA persistent object service (see Section 17.3) and Persistent Java
[Jordan 1996, iava.sun.com IV].
In generaL a persistent object store will manage very large numbers of persistent
objects. which are stored on disk lImil they are needed. They will be activated when their
methods are invoked by other objects. :\ctivation is generally designed to be transparent
- that is. the invoker should not be able to tell whether an object is already in main
memory or has to be activated before its method is invoked. Persistent objects that are
no longer needed in main memory can be passi\·ated. In most cases. objects are saved in
the persistem object store whene\"cr they reach a consistent state. for the sake of fault
tolerance. The persistent object store needs a strategy for deciding when to passivate
objects. For example. it may do so in response to a request in the program that activated
the object~. for example at the end of a transaction or when the program exits. Persistent
object stores generally attempt to optimize passi\'ation by saving only those objects that
have been m0dified since the last lime they were SJ.\"cd.
Persistent object stores generally allow coliections of related persistent objects to
have hU!l1::.n-readable names such as pathnames or CRLs. In practice. each human-
readable name is associated with the roO! of a connected set of persistent objects.
There 3re two approaches to deciding whether an object is persistent or nOl:
The ;ccrsislent object store maintains some persistent roOls and any object that is
reach:!hle from a persistent f(iot is defined to be persistent. This approach is used
by Per~istent Java and by PeiDiS [Ferreira cr al. 2000]. Persistent object stores
using ;hi~ approach make u~<.' of a garbage collector to di~pose of objects that are
no k';;.g:er reachable from Ihe persistent roOb.
The ~!~i:-;tentobject store pro\·idc:-. somc cla""es on \\:hich persistence i" based-
pcr~",<:'nt objects belong to their ~llbc1a~se~. For cxample. in Arjuna [Parrington
('i ai 1995], persistent objecl~ arc hased on C++ classes that pro\'ide transactions
and ,c.::cn·cry. Cnwanted objeo:- Illuq be ddeted explicitly.
Some per'>tenl object storc~. fe,r c\ampk PerDiS and Khazana (Carter ei d 1998J
allow objc.::" to be acti\·i.lled in llwilipk caches iocallO u"ers, instead of in ~er\crs. In
Ihis casco c: cache consistency pn,wcoi is required: Chapter 16 discusses J \'ariety of
consistenc. iTlodeb.
Object location 0 SeClion 4.3,.3 de<..cribc:-. a form elf remote object reference thal contains
the Interne: :ddrcss and port number of the proccss that created the remote object as a
way of guaranteeing uniqueness. This form of remote object reference can abo be used
as an addre"~ for a remote object so long ::IS that oh.iect remains in the same process for
the rest of lh life. But some remote objccts wi)) c\ist in a series of different processes.
182 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
possibly on different computers. throughout their lifetime. In this casco a remote object
reference cannot act as an address. Clients making invocations require both a remote
object reference and an address to \vhich to send invocations.
A location service helps clients to locate remote objects from their remote Object
references. It uses a database that maps remote object references to their probable
current locations - the locations are probable because an object may have migrated
again since it \Vas last heard of. For example. the Clouds system [Dasgupta er al. 199 i)
and the Emerald syslCm [Jul ef al. 1988] used a cachelbroadcast scheme in \vhich a
member of a location service on each computer holds a small cache of remote object
refcrence-to-location mappings. If a remote object reference is in the cache. that addre""
is tried for the invocation and will fail if the objeCt has moved. To jocate an object that
has moved or whose location is not in cache, the system broadcasts a request. Thi~
scheme may be enhanced by the use of forward location pointers, which contain hil1b
as 10 the new location of an object.
5.2.6 Distributed garbage collection
The aim of a distributed garbage collector is to ensure that if a local or remote reference
to an object is still held anywhere in a set of distributed objects, then the object itself\\ iil
continue 10 exist. but as soon as no object any longer holds a reference to it. the objc(l
\,'ill be collected and the memory it uses reco\·ered.
\Ve describe the Java distributed garbage colleCIion algorithm, \';hich is similar 10
the one described by Birrell e{ at. [19951. It is ba:,-cd on reference counting. Whenen'r:l
remote object reference enters a process, a proxy will be created and will :'-lay there for
as long as it is needed. The process where the object li\"es (its servcr) should be informed
of the new proxy at the client. Then later \vhen there i:,- no longer a proxy at the client.
the server should be informed. The distributed garbage collector work.~ in cooperation
with the local garbage collectors as follows:
Each sen'cr process maintains a set of the processes that hold remote ObjCL'I
references for each of its remote objects: for example. B.llo/ders is the set of eliem
processes (virtual machines) that have proxie.<.. for object B. (In Figure 5.6. thi." .~el
will include the client process illustrated.) Thi" set can be held E1 an addition;:!
column in the remote object table.
When a client C first receives a remote reference to a particular remote object. B
il makes an addR(,/(B) in\'ocalion to the :-.e,\"(::r of that rcmote 0bject and then
create" a proxy: the sen'er adds C to B.holder.l.
When a client C" garbage collector notice" thm a proxy for remote object B i<.. f:l1
longer reachable. it makes a remOl'cRef( B) invocation to the c()rTe~ponding ser\ e,
and Ihen deletes the proxy: the sen'er re11l0w<.:. C from B.ho/ders.
When B.liolden is empty, the server's IOC21 garbage collector . .,ill reclaim
space occupied by B unless Ihere arc an) iocal holders.
This algorithm is intended to be carried out by means of pairwi:.;" request-rep1~
communication \vith at-most-once invocation semantics between the remme n:fcrence
modules in processes ~ it does not require any global :,-ynchronil.ation. :"Ole also that Ihc
SECTION 5.3 REMOTE PROCEDURE CALL 183
extra invocations made 011 behalf of the garbage collection algorithm do not affect every
normal RMI: they occur only \\:hen proxies are created and deleted.
There is a possibility that one client may make a removeRef( B) invocation at about
the same time as another client makes an addR(f(B) invocation. If the remm'eRefarrives
first and B.lw/ders is empty, the remote object B could be deleted before the addRef
arrives. To avoid this situation. if the set B.holders is empty at the time when a remole
object reference is transmiHed, a temporary entry is added until the addR(farrives.
The Java distributed garbage collection algorithm tolerates communication
failures by using the following approach. The addR({ and removeRcf operations are
idempotent. In the case that an addR({(B) call returns an exception (meaning that the
method was either executed once or not at all). the client wil! Ilot create a proxy but will
make a renwl'eRef( B) call. The effect of remm'eRefis correct whether or not the addRef
succeeded. The case where remol'cReffails is dealt with by leases, as described in the
next paragraph.
The Java distrihuted garbage collection algorithm can tolerate the failure of client
processes. To achieve this. servers /eose their objects to clients for a limited period of
time. The lease period starts when the client makes an addRefinvocation to the server.
It ends either when the time has expired or \vhen the client makes a remm'eRef
in\'ocation to the server. The information stored by the server concerning each lease
contains Ihe identifier of the client's virtual machine and the period of the lease. Clients
arc responsible for requesting the server 10 renew their leases before the: expire.
Leases in Jini 0 The Jini distributed system includes a specification for lea~cs [Arnold
e! at. 1999J that can be llseci in a yariety of situations when one object offer:-. a resource
to another object. as for example when remote objects offer references to other objects.
Objects that offer such resources arc at risk of ha\'ing to maintain the resources when the
u<.ers arc no longer interested or their programs may have exited. To a,'oid complicated
protocols to discover whether the resource users are still interested. the re<.()urces are
offered for a limited period of time. The granting of the use of a resource lor a period of
time is called a leas£'. The object offering the resource \vill maintain it unlilthe lim(: in
the lease expires. The resource users are responsible for requesting their renewal when
they expire.
The period of a lease may be negotiated between the grantor and the recipient.
although this docs not happen \\."ith the leases used in Ja\"a RMI. An object representing
a lease implements the Lease interface. It contains information abollt the period of the
1c<lse and methods enabling the lease to bc renewed or cancelled. The grantor returns an
instance of a Lease when it supplies a resourcc to another object.
5.3 Remote procedure call
,.; remote procedure call is very similar to a remote method invocation 1[") thai a client
In"
pmgram calls a procedure in another program running in a server proce<..~. Sen'ers may
be clients of other servers 10 allow chains of RPCs. As mentioned in the introduction lO
Ihis chaptcr. a server process defines in its .\en"icc inrclfacc the proccdures that are
,n'ailable fo!"calling remotely. RPC. like R;\·1L lllay he implemented 10 h<:l\c one of the
choices of inn)Cation semantics discllssed in Section 5.2.4 ~ at-least-on'~'e or at-111oSI-
 SECTION 5.3 REMOTE PROCEOURE CALL 185
184 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION

Role of client and server stub procedures in RPC Figure 5.8 Files interface in Sun XDR
Figure 5.7
COI1Sf MAX == 1000:
server process rypedefinr Fiieldenrijicr;
[ypede.( illt FiIePoinrcr:
. r ...... .r"'.._
"
.----~,
~
r '. [ypede! ill( U:llgth:
.
s[ruel Da{(l [

~. ~ "'-.-/
server stub
"-- fllt lengrh:
char lmffer/.'HAX j:
client stub
procedure procedure
service J.
client Sfrucr IITilcargs {
program Communication procedure
module Fileldent!fier f:
FilePoinrer posiiion:
Dawdaw:
once are generally chosen. RPC is generaliy implemented over a request-reply protocol J
like the one discussed in Section ..f.-I.. which is simplified by the omission of object srruCf readorgs {
references from request messages. The contents of request and reply messages are the Fileldenr([ier/:
same as those illustrated for R\H in Figure 4.13. except that the ObjeClReference fleJd FilePointer posirio!]:
Lf.'ngrh iengrh:
is omitted.
The software that suppom RPC is sho\,..·n in Figure 5.7. It is similar to that shown J
in Figure 5.6 except that no remote reference modules are required. since procedure call
is not concerned with objects anj object references. The client that accesses a service program FlLEREADHRITE {
includes one sHib procedure for each procedure in the service interface. The role of a l"('1"sio/l VERSION f
'."()id HRIT£(\,.,.ij('(;r'!s/=I:
stub procedure is similar to that or" a proxy. It beha\'es like a local procedure to the client.
but instead of executing the calL it marshals the procedure identifier and the arguments Data READlreaddrgsi=2:
into a request message, which it :,-cnds \'ia its communication module to the server. J=2,
When the reply message arri\·es. it unmarshals the results. The ser\'er process contains ./ == 9999:
a dispatcher together with one :'-e,yer stub procedure and one service procedure for each
procedure in the service interface. The dispatcher selects one of the server stub
procedures according to the pro.:edure identifier in the request message. A server stub The Sun RPC sY:-'lem pro\'ides an interface language calle..:i XDR and an interface
procedure is like a skeleton method in that it unmarshals the arguments in the request compiler cailed rflcgen v, hich 1<, intended for use \\ ilh the C prc;ramming language.
message. calls the corresponding ~a\"ice procedure and marshals the return values for
the reply message. The sen'ice procedures implement the procedures in the sen'ice Interface definition language: The Sun XDR langu:lge. which '.,:,.... originally designed
for ~~cifying external data representations. \\ 2.'- extended become an interface
interface.
The client and server s!u~ procedures and the dispatcher can be generated by an definition language. It ma~ be used to define a :-.en·ice imci.·2.ce for Sun RPC b:
~pecif:- ing a set of procedure definitions together \\ ilh suppor1i,,; type definitions. The
interface compiler from the interface definition of the sen'ice.
notation is rather primiti\'e in comparison \vith th3t used by CORBA IDL or Ja\"a. In
particular:
5.3.1 Sun RPC case study :\10<.,[ language:-. all(w. llHerface names 10 be . . pecified. t·..:; Sun RPC does no, -
RFC 1831 [Srinivasan 1995a] de.;..:-ribe~ Sun RPC \\ hich was designed for cJient-scn'cr instead of thi:-.. a pr0fram number and a \ eFinn number :~r,; -upplicd. The progr;:;i!1
communication in the Sun r\FS r:C\v,ork file system. Sun RPC is sometimes called O:'\C number:, can be Obi3.1ned from a ccntral aUlnlxity to "lkw. ;"\ ery program \0 ha\ e
(Open Network Computing) RPC. It is :-.uppJied a:-. a part of the various Sun and other it:-. own unique numkr. The \'crsion llllmtc-er changes \'. n,;" ~ procedure signature
UNIX operating systems and is abo available with other NFS installatiom. changes. Both program and version number arc passed in :he request mes:-;age. ~0
Implementors have the choice 0'- using remote procedure calls over eithcr UDP or TCP. that cliem and scr\"er can check that the:- tire using the S3:;:e \"crsion.
When Sun RPC is used with CDP. lhe length of request and reply messages is restricted
in length - theoretically to 64 kilobytes. but more often in praC!icc to 8 or 9 kilobytcs. It
uses at-least-once call semantics. Broadcast RPC i~ an option.
 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
186
A procedure definition specifics a procedure signature and a procedure number.
The procedure number is used as a procedure identifier in request messages. (It
would be possible for the interface compiler 10 generate procedure identifiers.)
Only a single input parameter is allowed. Therefore. procedures requiring
multiple parameters must include them as components of a single structure.
The output parameters of a procedure are returned via a single result.
The procedure signature consists of the result type. the name of the procedure and
the type of the input parameter. The type of both the result and the input parameter
may specify either a single value or a structure containing several values.
For example. see the XDR definition in Figure 5.8 of an interface with a pair of
procedure~ for \vriting and reading files. The program number is 9999 and the version
number is 1. The RE.AD procedure (line 2) takes as input parameter a structure \vith three
components specifying a file identifier. a position in the file and the number of bytes
required. Its result is a :structure containing the number of bytes returned and the file
data. The VvRITE prclCedufe (line 1) has no result. The WRITE and READ procedures arc
given numbers I and 1. The number zero is reserved for a null procedure. which is
generated automatically and is intended to be used to test whether a server is available.
The interface definition language provides a notation for defining constants.
typedefs. structure~. enumerated types. unions and programs. Typedefs. structures and
enumerated types use the C language syntax, The interface compiler rpcgen can be used
to generate the following from an interface definition:
client qub procedures:
server main procedure. dispatcher and server stub procedures:
5.4
XDR marshalling and unmarshalling procedures for use by the dispatcher and
client and server ~lUb procedures,
Binding 0 Sun RPC runs a local binding service called the porI mapper at a well-known
port number on each computer. Each instance of a port mapper records the program
number. version number and port number in usc by each service running locally. When
a server starts up it regi~ters its program number. version number and port number with
the local port mapper. When a client ~!arts up. it finds out the servers port by making a
remote request to the port mapper at the server's host. specifying the program number
and version number.
When <t service has multiple instances running on different computers. the
instances ma: use diffr:-,ent port numbers for receiving client requests, If a client need;;
to mullicaq a reque~t to all the instances of a sen'ice that are using different pOr!
numbers. it cannot use <l direct broadcast message for this purpose. The solution is that
clients make mullica_" remote procedure calls by broadcasting them to all the port
mappers, specifying the program and version number. Each port mapper forwards all
such calls to the appropriate local service program. if there is onc,
Authentication 0 Sun RPC requeq and reply messages provide additional fields enabling
authentication information to be passed between client and sen'cr. The request message
contains the credential:-- of thc uscr running the client program. For example. in the
UNIX style of authentication the credentials include the aid and gid of the u:',er. Access
SECTION 5.4 EVENTS AND NOTIFICATIONS 187
control mechanisms can be built on top of the authentication information \vhich is made
available to the server procedures via a second argument. The server program is
responsible for enforcing access control by deciding whether to execute each procedure
call according to thc authentication information. For example. if the server is an NFS
file server. it can check whether the user has sufficient rights to carry out a requested file
operation,
Several diffcrent authentication protocols can be supported. Thesc include:
none:
UNIX style as described above:
a ~ty!e in which a shared key is established for signing the RPC messages: or
Kerberos style of authentication (sce Chapter 7),
A field in the RPC header indicates which style is being used.
A more generic approach to security is described in RFC 2203 [Eisler er at. 19971.
It provides for secrecy and integrity of RPC messages as \vell as authentication, It allows
client and server to negotiate a security context in \vhich either no security i:', applied or
in the case that security is required. message integrity or message privacy or both may
be applied.
Client and server programs 0 Further material on Sun RPC is a\·ailable at
,vww,cdk3,netiRMl. It includes example client and serwr programs corrc:',ponding to
the interface defined in Figure 5,8,
Events and notifications
The idea behind [he usc of events is that one object can react to a change occurring in
another object. :\otifications of events arc essentially a:--ynchronous and determined by
their receivers, In particular. in interacti\'e applicatIons. the actions that the user
performs on ohjects. for example by manipulating a button with the mou~e or entering
text in a text box via the keyboard. arc seen as el'el/fS that cause changes in the objects
that maintain the state of the application, The objects that arc responsible for di:;playing
a \'ir:-w of the current :State are 11()[(fied whenever the state changes.
Di:;rribuled e\'ent-based system:; extend the local cvcnt model by allo\\-ing
multiple object~ at different locations to be notified of e\'en!s taking place at an object.
They use the puNish,slIbscribe paradigm. in which ::n object that genr:-rmc" events
pllitlishcs the lype of c\ cnts that it will make a\'ailahlc f{lf observation by other objects.
Ohjects that wan\ to recei\'c notification" from an objeCi that has publi:.-hed its e\-ents
whscrihe to the lype:; of events that are of interest to them, Different en:::m rY{les ma:.
for exampk, refer to the different methods executed by the object of imcre:;l. Objects
that reprr:-sen! e\'ent:', are called IlOf((icarions, Notiflcations may· be stored. sent in
messages, queried and applied in a variety of order" to different things, When a
publisher expcriencc:.- an event. subscrihers that expres:"ed an interest in that l:::pe of
event will receive notifications. Subscribing to a particular type of event i~ aL"o called
regisrering interest in that type of event.
 SECTION 5.4 EVENTS AND NOTifiCATIONS 189
188 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION

Events and notifications cao be used in a wide variety of different applications. for figure 5.9 Dealing room system
example to communicate a shape added to a drawing. a modification to a document. the
fact that a person has entered or left a room. or that a piece of equipment or an Dealer"s computer External Dealer's computer
electronically tagged book is at a new locatioo. The latter 1\\'0 examples are made source
possible with the use of active badges or embedded devices (see Section 2.2.3).
Distributed event-based systems have two main characteristics: ....oJJ!~?,EQ!l.
Heterogeneous: When event notifications are used as a means of communication
between distributed objects. components in a distributed system that wefe not
designed to interoperate can be made to \vork together. All that is required is that
event-generating objects publish the types of events they offer. and that other objects / ..
subscribe to events and provide an interface for receiving notifications. For example. ~0<:::--/
. \'0.'I:i./ . ~ //
Bates et al. ! 1996J describe how event-based systems can be used to connect ~/ ~()/ -o/Ob/';·
~(), .,,'0/
heterogeneous components in the Internet. They describe a system in which / r:;~'j/ ICo'//OI7
• ~v/
applications can be made a\\'are of users· locations and activities, such as using Deaie(s computer " // Dealer's computer
computers, printers or electronically tagged books. They envisagt! its future usc in the otific3tion
context of a home network with commands such as: ·if the children come home. turn .-._--
on the central heating'
Notifica~iQ!"J .. ~.. _....,.. _. ,~.~.9tification
Asynchronous: Notifications are sent asynchronously by ('\·ent-generating objects to
;:.ll the objects that have subscribed to them to pre\·ent publishers needing to
~ynchronize \vith subscribers - publishers and subscribers need to be decoupled.
:\1ushroom 1Kindberg cf af. 1996] is a distributed e\"em-based system de~igned to
~upport collaborati\·c \\wk. in which the user interftl.cc displays objec!.,; repre~enting
External
source
-
Dealer

users and information objects such as documents and notepads within shared
\\ orkspaces called IICHt·ork pfaU's. The state of each place is replicated at the
c-omputers of users currently in that place. E\"ents arc used to dcscribe changes to
objects and to a user·s focus of interest. For example. an event could specify that a
particular user has entered or left a place or has perfonned a particular action on an
object. Each replica of any object to which particular types of events are releYant
subscribes to them and recei\"es notifications when they occur. But subscribers are
decoupled from objects experiencing events. because different users arc ac;:i\·c at
different times.
corresponding stock. There will be a scparate infon11ation provider process for
each e"\l<':mal source.
A dealer process creates an object [Q represent each named stock that the user asks
to hayc di~played. This local object subscribes to the object represcming that stock
at the rek\·ant information pro\·ider. h then recei\"cs all the information sent to it
in notifications and dispJays it to the ll~r.

.-\ '-ituation in \vhich e\"enb can be useful is illustrated in the following dealing room The communication of notification~ is shown in Figure 5.9.
example:
Event types .-\n event source call generate e\·ents of one or more different typcs. Each
Simple dealing room system 0 Consider a simple dealing room sy'"stem who"e ta"k is to
e\·ent has (ii,rihwcs that specify information about that evenL such as the namc or
al1o\;, dealers using computers to see the latest information abolll the market prices of
the ~tocks they deal in. The market price for a single named stock is represented by an iderHiti.er of the object that generated i1. the 0peration, its parameters and the time (or a
object with scveral instance yariables. The information arrives in the dealing room from ~equence numberl. Types and attributes are ll~ed both in subscribing to e\"ents and in
S<,:\·eral different external sources in the form of updates to some or all of the inswnce nouficJiions. When ~ubscribing to an c\·cnt. the type of event is specified. sometimes
\2.:"iables of the objects representing the stocks and is collected by proce,-"e~ we cail n~odi!ied \\ ith 3. criterion as to the qlues of the attributes. \Vhenever an event of that
information providers. Dealers arc typically imere~led only in their speciali:'-l '-locks. A
type occurs that matches the attributes, the interested parties will be notified. In the
de,iiing room system could be modelled by processes with twO different ta~k;.,:
deaiing room example. there is one ty·pe of e\·ent (the arrival of an llpdate to a stock),
An information provider process continuously rccei\"es new trading information and the allributC's might spccify the name of a stock. its current price, and latest rise or
from a single external source and applics it to the appropriate stock ObjcCI~. Each
fall. Dealers may for example specify thal the:- are interested in all (he events relating to
of the updates to a stock object is regarded a~ an event. The stock object
experiencing such e\·enb notifies all of the dealers who ha\"e subscribed 10 the a "lOCK Ri,h a particular name.
 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION SECTION 5.4 EVENTS AND NOTIFICATIONS 191
190

Obserrer objects: The main purpose of an observer is to decouple an object of

Figure 5.10 Architecture for distributed event notification interest from its subscribers. An object of interest can have many different
Event service '\ subscribers \vith different interests. For example. the subscribers may differ as 10 thc
type of events Ihey are interested in. or those sharing the same requirements as [0 type
object of interest

1.
r··~.

notHicaiion
.._.
subscriber

< ..J
may differ in the attribute \·alues that are of interest. It could over~complicate the
object of interest if it had to perform all of the logic for distinguishing between the
~J
needs of its subscribers. One or more observers can be interposed between an object
object of interest observer subscriber of interest and subscribers. The roles for observers are discussed in more detail in a
- -.. -~-------+,..... -.,~
notification
...
---~'"--.- ...- ...--- ~. subsequent paragraph.
2. notification _ ....
o
I----..
~

Publisher: This is an object that declares that it will generate notifications of

object of interest observer \ subscribe~ particular types of c\·ent. A publisher may be an object of interest or an observer.

3.
~.-.".
.~
...,=>--.-. ··~-··-·-·-~-notHlCatTo·n .----~~~=~.
~--
.~
Figure 5. J 0 shO\vs three cases:

5.4.1
"
The participants in distributed event notification
../
Figure 5.10 sho\\'s an architecture that specifies the roles played by the OQyxts that
participate in distributed event-based systems. Our description is derived from the paper
on events and notifications in the Internet by Rosenblum and \Volf [199-j. The
architecture is designed to decouple the publishers from the subscribers. allowing
publishers to be developed independently of their subscribers. and as far as possible
limiting the \\lork imposed on publishers by subscribers. The main compon:;Onl is an
event service that maintains a database of published events and of subscriber:=:: interests.
Events at an object of interest are published at the event service. Subscribers inlom the
event service about the types of events they are interested in. \Vhen an e\·enl c...::curs at
an object of interest a notification is sent to the subscribers to that type of eveil\'
The roles of the participating objects are as follows:
The o/~iect of intereST: This is an object that expericnces changes of state. ;::5 a result
of its operations being invoked. Its changes of state might be of intere~: :0 other
objects. This description allows for evenb such as a person wearing an aCIi\ C badge
entering a room. in which case the room is the object of interest and the ()p-cration
consists of adding information about the new person to its record of wh('· i~ in the
room. The object of interest is con:;.idered as part of the event sen· ice if it :ransmits
notifications.
E1·em: An event occurs at an object of interest a~ the result of the compl;;:,]on of a
method execution.
;VOli/iCUliol1: A notification is an object that contains information about ::':1 C\'CnI.
Typically. it contains the type of the event and its attributes. which genera);:- include
the identity of the object of interest. the method invoked. and the time of <.',:,:\.1r,ence
or a sequence number.
Suhscril)('r: A subscriber is an object that has subscribed to some lype: 0) c\cnts in
another objcct. It receives notifications about such evcnts.
1. An object of intcrest inside the Cycnt sen· ice without un obscr\·er. h sends
notifications directly to the subscribers.
2. An object of interest inside the evcnt service with an obser\·cr. The object of
interest sends notifications via the observer to the subscribers.
3. An object of interest outside the cvent service. In this casc. an observer queries the
object of intereq in order to discover v,·hen e\·enls occur. The obseryer sends
notifications to the subscribers.
Delivery semantics ': .4. variety of different delivery guarantee~ can be pro\·ided for
notifications - the one that is chosen should depend on the requirements of applications.
For example. if IP multicast is used to send notifications to a group of receivers. the
failure model will r<"jatc to the one described for IP multicast in Section 4.5.1 and will
not guarantee that 2.n; particular recipient will receiyc a particular notification message.
This is adequate for ~ome applications. for example to dcliycr the lalest o;tate of a pla):er
in an Intcrnet game. becau~e the next update is likely to get thwugh.
Howe\·cr. other applications haw stronger requirements. Consider the dealing
room application: 10 be fair to [he dealers interested in a particular :..rock. \\ <" require thal
all the dealers for the :'-ame stock receive the same informmion. This implies that a
reliable multicast protocol should be used.
In the Mu~hrcx)m system mentioned aboyc. nO!ifica[ion~ about thc change of
object state arc deli\ered reliably to a serYcr. whose responsibility it is to maimain up-
to-date copie~ of objeCts. Howevcr. notifications may also be ~ent to object replicas in
users' computer:;. b~ means of unreliable multicast: in the case that [hc latter lose
notifications. they carl rdrieyc an objcct state from the sener. When the application
require:'- il. notific,ltl\.\n~ may be ordercd and sent reliably to object replica~.
Some applicati(ln~ havc real-time requirements.These include c\·enb in J nuclear
power station or a h(\~pita) patient monitor. It is po:'-sib1e to de~if:n multicasl protocols
that pHn·ide real-limo;': guarantees as well as reliability and ordering in a :'-~ qcm that
smisfies the propen:ie.;. of a synchronous distributed ~y<,tem.
Roles for observers· .-\lthough notifications could be sent directly from [he object of
Intercst to the recipient. the task of processing nOlification<.. can be di\'id;:-d among
observer processe~ pkl; ing a variety of different roles. We descnoe some CX:itllp!cS:
192 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
Fon1'arding: A forwarding observer may carry out all the work of sending
notifications to subscribers on behalf of one or more objects of interest. All an object
of interest need do is to send a notification to the forwarding observer, leaving it to
continue with j(5 normal task. To usc a forwarding observer, an Object of interest
passes on the information about its subscribers' interests to that fOT\varding observer.
Filtering (~r llorijicalions: Filters may be applied by an observer so as to reduce the
number of oO!ifications received according to some predicate on the contents of each
notification. For example, an event might relate to withdrmvals from a bank account.
but the recipient is interested only in those greater than S100.
Patlems (~f e"enls: When an object subscribes to events at an object of interest. they
can specify patterns of events that they arc interested in. A pattern specifies a
relationship bel\l,;een several events. For example. a subscriber may be interested
when there are three withdri1wals from a bank account \vithout an intervening
deposit. A similar requirement i~ to correlate events at a variety' of objects of interest:
for example. notifying the subscriber only \vhen a certain number of them have
generated events.
Notificalioll mailboxes: in some cases. notifications need to be delayed until a
potential subscriber is ready to receive them. For example. if the subscriber has faulty'
connections or when an object has been passivated and is activated again. An
observer may take on the role of a notification mailbox. which is to rcceive
notifications on behalf of a subscriber. only passing them on (in a single batch) when
the subscriber is read::' to reccive them. The subscriber should be able to turn delivery
on and off as required. The subscriber sets up a notification mailbox. when it registers
with an object of interest by specifying the notification mailbox as the place to send
notifications.
5.4.2 Jini distributed event specification
The Jini distributed event specification described by Arnold er ai. [1999] allows a
potential subscriber in one Java Virtual i\.'lachine (JVM) to subscribe to and receive
notifications of e\'ents in an object of interest in another JV\·1. usually on another
computer. A chain of observers may be inserted between tbe object of interest and the
subscriber. The main objects invoh'cd in the Jini distributed e\'cnt 5pccification are:
E"em gener(l!ors: An event generator is an object that allows other objects to
subscribe to ib events and gcnenHes notifications.
RemOie f)'em fisrener.s: A remOle eVent listener is an object that can recei\'c
notifications.
RemOie e\'C'IITS: A remote c\"enl j~ an object that is passed by \"alue to remote C\"C!lt
listeners. A remote event is the equi\'alent of \\'hat we called a nOlification.
Third-party (('"elliS: Third-party agents may be interposed bct\veen an object of
interest and a subscriber. They arc the equiyalent of our obserwrs.
An object subscribes to eyents by informing the event generator about the type of event
and specifying a remOle event listencr as the target for notificatjon~.
SECTION 5.4 EVENTS AND NOTIFICATIONS 193
Java RMJ is used to send notifications from the event generator to the subscriber.
possibly via one or more first third-party agents. The designers state that event listeners
should reply to notification calls as soon as possible to avoid delaying event generators.
They can process a notification after the return. Java RMI is also used to subscribe to
events. Jini cvcnts are provided by means of the lo11owing interfaces and classes:
RClIlo[cE"emListcncr: This interface provides a method called l1or!fv. Subscribers
and third-party agents implement the RcmotcEvcmUstener interface so that they can
rceeive notifications when the nOI!fy method is invoked. An instance of the
RcmotcEl'c11£ class represents a notification and is passed as argument to the nor(f:r
melhod.
RemOfcE,'enr: This class has instance variables that hold:
a reference to the event generator in which the event occurred.
an eVent identifier. which specifics the type of e\'elll at that evcnt gener3.t()r.
a sequence number. which applies to events of that type. The sequence number
should increase as events occur over time. It can be used to enable recipients to
order e\'ents of a particular type from a given source or to avoid applying the
same event twice.
a marshalled objcct. This is supplied when the recipient subscribes to that type
of event and may be used by a recipient for any purposc. It generally holds any
infonnation necded by the recipient to identify the event and react to its
occurrence. For example. it could include a closure that is to be rlln when it is
notified.
E\'cntCeneraror: This interface provides a method called regisler. E\'ent generators
implement the b'emCeneralOl" interface. who~e regis!t'/" method is used to subscribe
to events at the e\'ent generator. The argumenb of register specify:
an e\ ent identifier. which specifics the type of cvcnt.
a marshalled object to be handed back with each notification.
3 remOle reference to an c\'ent li~tcner object - the place to >iend notifications.
a requested leasing period. The lease period ;:.pecifies the duration of lease
required by the subscriber. but the actual le'L~e granted is returned with the
result<. of rcgis{cr. Time limits on subscription;:. avoid the problem of e\'ent
generaIOrs holding stalc eyc!lt subscription~. Subscriptions can be renewed
\\'I1<:n<:\'<:r the time limit in the lease expires.
The Jini speCification says that the E"cl1{GC!1('l"(JlOr imcFface i" just an ex.ample of the
kind of interface that might be used by subscribers to register interest in e\'ent::; ill an
object of interest. Some applications may require a different imcrface.
Third-party agents (j The third-party agents thai are interpo~ed between an eyenl
generator and il subscriber may pb.y a Yariel)' of u.<,efu1 role.'.. including all of those
de~cribed ah()\"(2.
194 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
In the simplest case, a subscriber registers interest in a panicular type of event at
, Figure 5.11
an event generator and specifics itself as the remote event listener. This corresponds to
case 1 illustrated in Figure 5.10.
Third-party agents cao be set up by an event generator or by a subscriber.
An event generator can interpose one or more third-party agents between itself
and a subscriber. For example, the event generators on each computer could make usc
of a shared third-party agent that is responsible for reliable delivery of notifications.
A subscriber can build a chain of third-party agents in order to produce \vhatever
delivery policy it requires. It then registers interest with an event generator, specifying
the first in the chain of third~pany agents as the place to send notifications. For example.
a subscriber may arrange for its notifications to be stored by a third~party agent until
such time as it is ready to receive them. The third-pany agent can take responsibility for
renewing leases.
The CORBA Event Service is discussed in Section 17.3.2.
5.5 Java RMI case study
Java RMI extends the Janl object model to provide support for distributed objects in the
Java language. In particular. it allows objects to invoke methods on remote objects using
the same syntax as for local invocations. In addition. lype checking applies equally to
remote invocations as to local ones. However. an object making a remote invocation is
aware that its target is remote because it must handle RcmotcExcCpliol1s: and the
implementor of a remote object is aware that it is remote because it mUSt implement the
Remote interface. Although the distributed object model is integrated into Java in a
natural way. the semantics of parameter passing differ because invoker and target are
remote from one another.
The programming of distributed applications in Java RMI should be relatively
simple because it is a single-language :.ystem - remote interfaces are defined in the Ja\'a
language. If a multiple-language system such as CORBA is used. the prog:rammer needs
to learn an IDL and to understand how it maps onto thc implementation language.
However. even in a single-language system. the programmer of a remote object must
consider its behaviour in a concurrent environment.
In the remainder of this introduction. we give an example of a remote interfacc.
then discuss the parameter-passing semantics with reference to the example. Finally. we
discuss the downloading of classe" and the binder. The second section of this case study
discusses how to build client and server programs for the exampJe interface. The third
section is concerned with the design and implementation of Ja\'a RMI. For full details
of Java RMI. see the wtorial on remote in\'oc<nion [java.sun.com II·
In this case study and the CORBA case study in Chapter 17. we use a shared
'.vhilcboard as an example. This is a distributed program that allows a group of users to
share a common view of a drawing surface containing graphical objects. such as
rectangles. lines and circles. each of which has been drawn by onc of thc users. The
server maintains the current state of a dra\1.:ing hy' pro\"iding an operation fOf client~ to
inform it about the latest ~hapc their users have dra\\:n and kceping a record of all the
shapes it has received. The server also proYide~ operations allowing cliems to retricye
Java Remote intertaces Shape and ShapeUst
SECTION 5.5 JAVA RMI CASE STUDY 195
import jaFa.nni.:";
imporl java. uri!. VeCTor:
public interface Shape ex/ends Remole (
int getVersioll() throws RemoreExceprion:
GraphicalOhjecf gerAllSwte() throws RemoreException;
public into/ace ShapeLisr exrends Remote (
Shape ne\lShape(GraphicalObjecr g) throws RemoreExcepliol1: 2
Vector aliShapes() throw, RemoreExccprion:
int gerVersion() thrmn RemOleExceprion:
the latest shapes drawn by other users hy polling the sen·cr. The servcr has a version
number (an integer) that it increments each time a new shape amves and attaches [0 the
new shape. The server proyides operations allowing clients to enquire about its version
number and the version number of each shape. so that they may 3\"oid fetching shapes
that they already have.
Remote interfaces in Java RMI (l Remote interfaces are defined by extending an
interface called Remote proyidcd in the jam.rmi package. The methods must thrO\v
RemoteExceprion. but application-specific exceptions may also be thro\vn. Figure 5.11
shO\vs an example of t\VO remOle interfaces called Shape and ShapeLisr. [n this example.
GraphicalONcu is a class that holds thc state of a graphical object. for example its type.
its position. enclosing rectangle. line colour and fill colour. and provides operations for
accessing and updating its statc. GraphicarObject must implement the Seria{i::.abfe
intenace. Consider the interfaCe Shape first: the gcr1/crsioll method rcturns an intcger.
whereas the gelAflSwre method returns an instance of thc class Graphic(lIOf~iecl. Now
consider the intenace SJwpeLisr: its l1cHShapc method passes an instance of
GraphicuiObjcu as argument but returns an object with a remote interface (that is. a
remote object) as its result. An important point to note is that both ordinary objects and
remote objecls can appear as arguments and results in a remotc interface. The latter arc
always denoted by the name of their remotc interface. In the next paragraph. we discuss
how ordinary objects and remme objects are passed as arguments and results.
Parameter and result passing (~ In Java R:\1L the parameter" of a method are assumed to
be inpul parameters and the re<.uit of a method is a single OI/If1W parameter. Section 4.3.2
describes Jan serialization. \~-hich is llsed for marshalling arguments and results in JaY;J
RMI. Any object that i:. serializable - that is. that implements the Seriafi:able interface
- can be passed as an argument or result in Java RMI. AI) primiti\"c types and remot,;:
objects are serializable. Classc::, for arguments and rcsult niu,;:s are downloaded to the
recipient by the R:'VlI system ,,"here necessary.
Passing rCll10le o~iccrs: When the type of a parameter or result value is defined as
a remote interface. the corresponding argument or result is always passed as a remote
object reference. For exampk in Figure 5.11. line 2. the return \'alue of thc method
196 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
l1f.'wShape is defined as Shape - a remote interface. When a remote object reference
is received. it can be used to make RMJ calls on the remote object to which it refers.
Passing nOll-remote objects: All serializable non-remote objects are copied and
passed by value. For example, in Figure 5.11 (lines 2 and I) the argument of
nel\Shape and the return value of getAllState are both of type GraphicalObjecL
which is serializable and is passed by value. When an object is passed by value. a new
object is created in the receiver's process. The methods of this new object can be
invoked locally. possibly causing its state to differ from the state of the original object
in the sender's process.
Thus. in our example. the client uses the method newShape to pass an instance of
CraphiC'{/IObjecl to the server: the server makes a remote object of type Shape
comaining the state of the GraphicafObject and returns a remote object reference to it.
The arguments and return \'alues in a remote invocation are serialized to a stream u~ing
the method described in Section 4.3.2. with the following modifications:
I. V/henever an object that implements the Remote interface is serialized. it is
replaced by its remote object reference, which contains the name of its (the remme
object's) class.
") When any object is serialized. its class infonnation is annotated with the location
of the class (as a CRU. enabling the class to be downloaded by the receiver.
Downloading of classes (, ]a\'3 is designed to allo\v classes to be downloaded from one
virtual machine to another. This is particularly relevant to distributed object~ inm
communicate by means of remote in\"ocation. \Ve have seen that non-remote objects are
passed by value and remote objects are passed by reference as arguments and result~ of
R\lIs. If the recipient does not already possess the class of an object passed by value. its
code is downloaded aUlOmatically. Similarly. if the recipient of a remote object
reference does not already possess the class for a proxy. its code is downloaded
automatically. This has t\\O advantages:
J. There is no need for every user to keep the same set of classes in their working
environment.
") Both dient and "er\'er programs can make transparent use of instances of new
classes whenever the) are added.
A" an example. con~ider the whiteboard program and suppose that its lnilial
implementation of CrapilicafObjecr does not allow for text. Then a client with a k'xtuai
object can implement a :,ubclas:,- of GraphicalONecr that deals \\'itn te:\! and P::b<. an
inqance to the ser\"er as an argument of the l1ell,Shape method. After that. other cli:::!lts
may retrieve the instance using the gerAlfSwte method. The code of the new cJ2.:'"!- \\'ili
be downloaded automatically from the first client to the server and then to other .:licnts
a' need.::d.
RMlregistry 0 The Rivllregistry is the binder for Java Rl\H. An instance of R\11registry
must nm on every sen er computer that hosts remote objects. It maintains a ~3.b!c
mapping textuaL CRL-style names to references to remote objects hosted on th:::\
SECTION 5.5 JAVA RMI CASE STUDY 197
Figure 5.12 The Naming class of Java RMlregistry
~'oidrebind (String name, Remote ol~;)
This method is used by a server to register the identifier of a remote object by name,
as shown in Figure 5.13, line 3.
,'oid bind (String name, Remote obj)
This method can alternatively be used by a server to register a remote object by name.
but if the name is already bound to a remote object reference an exception is thrown.
mid llnhind (String name. Remote obi)
This method remO\'es a binding.
Remme /ookup(String name)
This method is used by clients to look up a remote object by name. as shown in Figure
5.15 line J. ;\ remote object reference is returned.
S'!ring fJ fiSI()
This method returns an array of Siring.\· containing the names bound in the registry.
computer. It is accessed by methods of the Naming class. whose methods take as
argumcnI a CRL-formatted string of the form:
//com flU re rNa 111 e :po rl/obj ec t,\'a me
where compulerName and port refer to the location of the RMlregistry. If they are
omitted. the local computer and default port are assumed. II:. interface offers the
methods shown in Figure 5.12. in which the exceptions are not listed - all of the methods
can throw RemoreException. This sen'ice is not a system-wide binding service. Clients
must direct their lookup enquiries to particular hosts.
5.5.1 Building client and server programs
This section outlines the steps necessary to produce client and serycr programs that use
the Remmc interfac.::s Shape and ShapeLisr shown in Figure 5.11. The server program is
a simplified \'ersion of a whiteboard server that implements the t\\ 0 interfaces Shape and
S/wpcLisr. We describe a simple polling client program and then introduce the callback
technique that can be used to avoid the need to poll the server. Complete \'ersions of tne
classes illustrated in this scction are available at cdU.neUrmi.
Server program 0 The sen'er is a whiteboard server: it represents each shape as a remote
object that implements the Shape interface and holds the state of a graphical object as
well as its version number; it represents its collection of shapes t>y a remote object that
implements the ShapeLis[ interface and holds a collection of shapes in a VeCfor.
The sCr\'er consists of a main method and a servant class to implement each of its
remote interfaces. The main method of the server creates an instance of
ShapcLisfSerl"G/1l and binds it to a name in the RMlregistry. as ~hown in Figure 5.13
(lines 1 and 2). :':ote that the value bound to the name is a remote object reference. and
its type is the type of its remote interface - ShapeList. The twO sen'ant classes arc
5;hapcLisISerl"(mr. \\'hich implements the ShapeUsl interface, and SJwpeSerrant. which
198 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
Figure 5.13 Java class ShapeListServerwith main method
import java.rmi. :~:
public class ShapeListServer!
puhlic static Foid main(String args[ ] i{
5ys(em.setSecuriryMallager{ ne,,' R:'t1ISecllrityManager( ));
II)"{
Shape List aShapeLis(:::: nell' ShapeLisrSen:anr():
Naming.rebindC'Shape List", aShapeList ):
Sysrem.out.println( "ShapeLisr sel .... er ready"):
}carch(Exceprion e) (
Sysrcm.ouf.prinrfn( 'ShapeLisf sen:a main" + e.gcrMessage( )):}
Figure 5.14 Java class ShapeListServant implements interface ShapeList
importjam.rmi. "':
imporl jan;. rmi.soYCI". UnicasrRemoleObjecr:
import jam.uti!. Vecror:
public class ShapeLisiSerw1I1i e.':rel;ds CnicasrRemOlcObjecl imp/ell/ems ShapeList {
primre Vector (heLisE: II comains [he lisr of Shapes
prinue inr l'ersion:
public ShapeLisrServall[{ IjhrOlrs RemoreExceptioll{ ... }
public Shape nell-5hape(CraphicaIObjecr g) 1111"0,\,'05 RemorcExcepri(J11 {
l'ersion++:
Shape s :::: /lef1' ShapeSfn"(llll( g. l'ersion):
rheLiSi.addElementls !:
re!llrll s:
public Vec[(}r nltShapesl iiiJrm':s RemoreExceplion{. .. }
jJuhlic 1m ger\'ersion(j rhr01",s RellloteExcep!iol1 { ... }
irr.plement:'> the Shapf interface. Figure 5.14- gives an outline of the class
ShC;pfLisrSerl"am. \'ote that S!WIltLisrSerl"(Ul[ (line J). like man; "en'ant dasses.
C\tends a class named CniCaSiReJ/1o:eObjecr. which provides remote objects that 1i\"c
only as long as the proce"" in which lhey are created.
The implementations of the methods of the remote interface In a sen'anl class is
completely straightfof\\ ard beeau~e they can be done \vithout any concern for the details
of communication. Consider the mdhod of nc\\"Shapc in Figure 5.14 (!ine 2). which
could be called a factory method bcu.use it allows the client to reque<.t the crealion of it
remote object. It u"e~ the constructor of ShapeSeIT(lJ({. which creales a ncw remOle
SECTION 5.5 JAVA RMI CASE STUDY 199
Figure 5.15 Java client of ShapeList
import java.rmi. ¥:
import java.rmi.sen'er. "';
import java.wil. Vector:
public class ShapeListc/ienf{
public .'Italic void mainfString args[}){
System.setSecurityManager(nelv RMfSecllrityManager( )j:
2 ShapeList aShapeLisr:::: null:
try!
aShapeList :::: (ShapeLisr) Naming.!ookllp("llbrul1o.ShapeLisr'):
Veuor SLiSl :::: aShapeLisr.allShapes(): 2
} catch(RemofeException e) !5iystem.out.prinrin(e,gcfiWessagcl II:
jcatchrExceplior! e) (S>"5tem.oul.primln("ClieJ1!: ., + c.gerMeS5(igd i)
object containing the GraphicalObject and version number passed as arguments. The
type of the return value of neHShape is Shape - the interface implemented by the new
remote objec!. Before returning. the method /len'Shape adds the new shape to it~ n~ctor
that contains the list of shapes (line 3).
j
The main method of a scn'er needs to create a security manager [0 enable Jaya
security to apply the protection appropriate for an RMI sef\·er. A default security
manager called RMfSeclIriryManager is provided. It protects the iocal resources to
ensure that the classes that are loaded frolll remote sites cannot hBse any effect on
:2 resources such as files. but it differs in allowing the program to pro\'jde its O\,,,'n class
loader and to use reflection. If an RMI scn'cr sets no security manager. proxie~ and
3
ciasses can only be loaded from the local c!asspath. in order to protect the program from
code that is downloaded as a result of remote method in\·oCalions.
Client program 0 A simplified client for the ShapcLisr sen'er i<.. illu<..lratcd in Figure
5.! 5. Any client program need" to get started by using a binder to look up a remote
object referencc. Our client sets a security manager and then look:; up a rcmote object
reference for the remote object u:;ing the lookup operation of the R~'lIfcgi:;lry (line i).
Haying obtained an initial remote object reference. the client cODlinue~ b: ~('nding R\lb
to that remote object or to others discovered during ilS execution according to the necds
of ib app!icalion. In Ollr example. the client invokes the method aiiSfw{Jc\ in the remote
object (line 2) and recei\'c:,> a \"ector of rcmote objeCt reference:, w ;:ll "f the ~h"pe~
currently stored in the "cn·cr. If thc client was implementing H \\'hilt:bc'~:rd di:;.pby. it
wouid usc the servcr'" gerAlISrare method in the Shajlc interface to ft:tne\(' each of the
graphical objects in the \"ector and display them in a window. Each time tht: u"cr fini"he:,
drawing a graphical object. it will invoke the method 11(',\-5hape in tht: "en"Cr. pa~~ing
on the new graphical object as argument. The diem \\'ill kecp a record of the latest
version number at the sen·cr. and from time to time it will im'oke gcr\ 'asion at the
seryer to find out whether any new shapes ha\'c been added by other u~~'r .... If so. it \,'ill
retrieve and display them.
 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION
200
Callbacks 0 The genera! idea behind callbacks is that instead of clients polling the server
to find out whether some event has occurred, the server should inform its clients
t Figure 5.16
whenever that event does occur. The term callhack is used to refer to a server's action
of notifying clients about an event. Callbacks can be implemented in RMI as follows:
The client creates a remote object that implements an interface that contains a
method for the server to call. We refer to this as a callback object.
The server provides an operation allowing imerested clients to inform it of the
remote object references of their callback objects. It records these in a list.
Whenever an event of interest occurs, the serycr calls the interested clients. For
example. the whiteboard server \""ould call its clients whenever a graphical object
5.5.2
is added.
The usc of callbacks avoids the need for a client to poll the objects of interest in ;:he
ser\"er and its attendant disadvantages:
The performance of the server may be degrad<::d by the constant polling.
Clients cannot notify users of updates in a timely manner.
However. callbacks have problems of their own: fiN the sen'er needs to have up-to-date
lists of the clients' callback objects. But clients may not always inform the ser\"er before
they exit. leaving the server with incorrect li:;1s. The leasing technique discussed in
Section 5.2.6 can be used to overcome this problem. The second problem associated
\l.:ith callbacks is that the server needs to make a ~<::ries of synchronous RMh 10 the
caliback objects in the list. See Section 5.4.! and Exercise 5.18 for some ideas about
soh'ing the second problem.
We illustrate the use of callbacks in the conte:>:! of the whiteboard application. The
p.,'hirehoardCalfback interface could be defined a::.. follows:
public ilUoface "VhireboardCallhack implemenis Remote (
void callback(inr version) [hro~\'s RemmcD:ception:
J reference of the target will have been u::2Jarsha!led and the corre::;ponding local object
This intcrt-acc is implemented as a remote object b: the client. enabling the ser\'er to
send the client a version number whenever a ne\\ object is added. But before the serwr
can do this, the client needs to inform the sen'er about its callback object. To make this
possible. the ShapeUsr interface requires addiuonal methods such as regisler and
deregislcr, defined as follows:
in! regisrer(WhiteboardCafl!Jack callback i rhrr .... s RemoreE"(("cplioll:
\'oid deregisrer(int callhackld) throws Rem()£(Excepfi{JIl:
Afler the client has obtained a reference to the reJ11ot<? object with the ShapeUsr inkrf2ce
(for exampJe in Figure S.15.line I) and created an instance of its callback object. it mes
the register method of ShapeLisr to inform the sen<?r that it is interested in recei\'ing
callbacks. The register method returns an i!1leger (the ca/lbacUJ) referring to the
registration. When the client is finished it should cail deregister to inform the senTi it
no longer requires callbacks. The server is re:-.pol1"'-ib1e for keeping a list of interested
clients and notifying all of them each time it:-. \'er~ion number increases.
SECTION 5.5 JAVA RMI CASE STUDY 201
Classes supporting Java RMI
RemoteObject
\
RemoteServer
/ \
Activatabfe UnicastRemoteOb/ect
\
<ser,lant class>
Design and implementation of Java RMI
The original Ja\'a RMI system llsed all of the compon<?nt~ ~hown in Figure 5.6. Bm in
Java 1.2. the reflection facilities were u,cd to make a generic dispatcher and to a\'oid the
need for skeletons. The client proxie~ arc generated Q: a compiler called rmic from the
compiled server classes - not from the jdinitions of the remote interfaces.
Use of reflection 0 Relleetion is used \(l pass information in request messages abollt the
method to be invoked. This is achieved" ith the help ofthc c!a",-s Merhod in the reflection
package. Each instance of Method repr2~<::ms the charact<::ri~tics of a particular method.
including its class. the types of its arguments. return \;:ilue and exceptions. The most
interesting feature of this cbss is that an :n",-lance of .thi.W,j can be in\"oked on an object
of a suitable class by means of ib in'. ,~.(' method. The iO\'oke method requires [\\0
arguments: the first specifies the object to receive the l11\(X"ation and the second is an
array of Object containing the argumen,'-. The result j, rewmd as type Objecr.
To return w the use of the ,if{:i;od class in R\!I: the proxy has to marsh,,-l
information about a method and its argu;T1<::l1ts into the n::quc.\r message. For the method
it marshals an object of class Method. [, ;'UIS the argum2nt~ into an array of Objecrs and
then marshals that array. The disp~~,~'~,cr unmar::..hab the .\1eihod object and iF
arguments in the array of O/~ieC!s from ,:-.0: request me~:-age.:\~ usual. the remote object
reference obtained from the remote rc:'c,ence module. The di~patch<::r then calls the
.'vfeihod object's inl"OJ.:e method. suppl: ::-:; the target .::;:d [he array of argumem \·alue:-.
When the method has been executec. ,he dispakh<?, mar~hals [he result or an\
exceptions into the repty message.
Thus the di:'>palchcr is generic - is, the ~;;me di~patchcr can be u~ed for all
classes of remote object. and no skelel.:':> J.re requir<?J.
Java classes supporting RMI 0 Fig-un:::- . J..:. ,hows the ;nr,;:Tlianc<? qrucmre of the clas~-:>
supporting 1a\"a R\lI servcrs. The oni: ..::":-,, that the f""~frammcr need be aware of l~
UlliC(lslRcIIlOEeObjccr. which c\'ery ... ir;';;-1c scn'ant ~'l.::" need:- to c\icnd. The c!,!'"
Ullic(lsrRelll()feOl~ieCl eXlCnds an abq,,,,..:: -.:lass called RemorcSell"C/". \\'hich pro\'idc~
abstract \"<.:rsions of the methods r<.:quirc.:i :--y remote :-<::r, a~. CnicasrRemnreObjcc; \\ 2:-
the first example of RemoreSerrer to r...:: provided. An<.,ther calicd ACiiniloMe is no\,
a\'ailabk for pro\'iding activatabic Or.J;?':lS. Further :::.Ilemati\"es might pro\'ide for
replicated objects. The class RemOfeSer-.o· is a subda" Ill' R('I1!meOhjec{ lhJ.t has an
 SECTION 5.6 SUMMARY 203
202 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION

\vork of processing events. for example filtering and looking for patterns. can be carried
instance variable holding the remote object reference and provides the follO\ving
out by observers - third-party objects added to the system for that purpose.
methods:
equals this method compares remote object references:
toString: this method gives the contents of the remote object reference as a String: EXERCISES
readObject. writeOhject: these methods deserialize/serialize remote objects.

In addition, the instanceD! operator can be used to test remote objects. 5. The Election interface provides two remote methods:

5.6 Summary
This chapter has discussed two paradigms for distributed programming - remote method
invocation and event-based systems. Both of these paradigms regard objects as
independent entities that can receive invocations from remote objects. In the first casco
a method in the remotc interface of a particular object is invoked synchronously - with
the invoker waiting for a reply. In the second case. notifications are sent asynchronously
to multiple subscribers whenever a published event occurs at an object of interest.
5.2
The distributed object model is an extension of the local object model used in object-
based programming languages. Encapsulated objects foml useful components in a
distributed system. since encapsulation makes them entirely responsible for managing their
own state. and local invocation of methods can be extended to remote invocation. Each
object in a distributed system has a remote object reference (a globally unique identifIer) 5.3
and a remote interface that specifies which of its operations can be invoked remotely.
Local method invocations provide exactly-once semantics. whereas remote
method invocations cannot guarantee the same becaus.e the t\>',o participating objects arc
5.4
in different computers. which can fail independently and are linked by a network. which
might also fail. The best that can be managed is at-most-once call semantics. Due to their
different failure and performance characteristic~ and to the possibility of concurrent
access to remote objects. it is not necessarily a good idea to make remote invocation
appear to be exactly the same as local invocation.
lv1idd1eware implementations of RMI provide components (including proxies.
skeletons and dispatchers) that hide the details of marshalling. message passing and 5.5
locating remote objects from client and server programmers. These components can be
generated by an interface compiler. Java Ri'vlI extends local invocation to remote
invocation using the same syntax. but remote interfaces must be specified by extending
an interface called Remote and making each method throw a RemoteEw."cptiol1. This
ensures that programmers know when they make remote invocatiom or imp!cment
remote objects. enabling them to handle en'ors or to de:'>ign objects suitable for
5.6
concurrent access.
Distributed event-based systems can be used to a11O\\' distributed collections of
heterogeneous objects to communicate with one another. Unlike RML objects do not
need to have remote interfaces to receive message:'> - all they need to do is to implement
5.7
an interface for receiving notifications and to subscribe to events. Objects that generate
events need to send asynchronous notifications. The simplicity of interfaces should
make the addition of e\'ents to existing objects quite straightforward. The additional
w)te: with two parameters through which the client supplies the name of a
candidate (a string) and the 'voter's number' (an integer used to ensure each user
votes once only). The voter's numbers are allocated sparsely from the range of
integers to make them hard to guess.
result: with two parameters through which the server supplies the client with the
name of a candidate and the number of votes for that candidate.
Which of the parameters of these twO procedures are il/pw and which are OllfpW
parameters': page 167
Discuss the invocation semantics that can be achieved when the request-reply protocol
is implemented over a TCP/IP conneClion. which guarantees thar data is deli\'ered in the
order sent. without los" or duplication. Take into account all of the condition::. causing a
connection to be broken. Section 4.2.4 and page 174
Define the interface to the EleCTion ::.ervice in COREA IDL and Java Rl\'1I. :\"ote that
CORBA IDL provides the type long for 32 bit integers. Compare the methods in the two
languages for specifying inpur and OWpUI arguments. Figure 5.2 and Figure 5.11
The Eleoioll sen'ice mu"t ensure that a \·ote is recorded whenever any user thinks they
have cas! a \·ote.
Discuss the effect of maybe call semantics on the Elecrioll service.
\Vould at-1east-once call semantics be acceptable for the Election service OJ ,,'ould you
recommend at-mast-once cail semantic:.:) r!{!ge 175
A requesHcply protocol is implemented o\"o.':r a communication <;ervicc \\ ith omission
failures to provide at-lea~t-once R\l"l invocation semantics. In the fir", case the
implementor assumes an asynchronous distrit1llted syqem. 1n the <.,cconG case the
implementor assumes that the maximum time for the communication and the execution
of a remme method is T. ln what way doc:-. the laner assumption :--lmplify the
implementation? page 17-+
Outline an implementation tor the Etcciiol1 ser\·ic<.'! that elbl1re~ that it~ rec0rd;.. remain
consiqem when it is accessed concurrently by multiple cli<.'!l1b.
[loge 176
The Eteoioll service must ensure that all \'otes 3re -"afel)" stored e\'en when ,he seryer
process crashes. Explain how this can be achie\'ed with reference to the implementation
outline in your ans\\"cr to Exercise 5.6. page.\ i80-1Si
 EXERCISES 205
204 CHAPTER 5 DISTRIBUTED OBJECTS AND REMOTE INVOCATION

Show how to use Java reflection to construct the client proxy class for the Election
5.8
interface. Give the details of the implementation of onc of the methods in this class.
\\I"hieh should call the method doOperatioll with the follO\ving signature:
byte [J doOperation (RemoteObjecrRef 0, Method m, by/c[ ] arguments);
Hint: an instance variable of the proxy class should hold a remote object reference (see
Exercise 4.12). Figure 4.12 and page 201
Show how to generate a client proxy class using a language such as C++ that does not
5.9
suppOrt reflection. for example from the CORBA interface definition given in your
answer to Exercise 5.3. Give the details of the implementation of onc of the methods in
this class. \vhich should call the method doOperarioll defined in Figure 4.12.
page J 79
Explain how to use Java reflection to construct a generiC dispatcher. Give Java code for
5.10
a dispatcher whose signawre is:
Pllblic void dispatch(Object larger. Method aMelizod. byre[j (lrgs)
The arguments supply the target object. the method 1:0 be invoked and the arguments for
that method in an array of bytes. page 20j
Exercise 5.8 required the client to convert Ol~iect arguments into an array of bytes before
5.11
invoking doOperatiol1 and Exercise 5.10 required the dispatcher to con\'ert an array of
bytes into an array of Objects before imoking the method. Discuss the implementation
of a new version of doOperalioll with the following signature:
Object [] doOperalioll (RemoteObjectRef o..Herhod m. Ohject{j arguments):
which uses the ObjeCiOurpJaSrream and ObjecrlnpurStream classes to stream the
request and reply messages between client and ~erYer oyer a TCP connection. Ho\\
would these changes affect the design of the dispatcher': Section 4.3.1 and page 201
A client makes remote procedure calls to a serwr. The client takes 5 milliseconds 10
5.12
compute the argumenlS for each request. and the ser'er takes 10 milliseconds to process
each request. The local operating system proce_~:,ing time for each send or recei\'c
operation is 0.5 milliseconds. and the net\\'ork time to transmit each request or repiy
message is .3 milliseconds. :v1arshalling or unmar"ho.lling takes 0.5 milliseconds pcr
message.
Calculate the time taken by the client to generate and return from twO requests:
5.14 A simpler version of the distributed garbage collection algorithm described in Section
5.1.6 ju.st invokes addRef at the .site v,,'here a remote o~ieCl live.s \vhenever a proxy i~
created and removeRefwhenever a proxy is deleted. Outline all the possible effects of
communication and process failures on the algorithm. Suggest how to o\"Crcome each of
these effects. but without using leases. page 182
5.15 Discuss hov.: to use events and notifications a~ described in the Jini distributed event
specification in the context orthe shared whirehoard application. The RemOleEFen{ class
is defined as tollows in Arnold er al.[19991-
puhlic class RemoreEvent eXlendsjara.uril.E,·eIl10bjecl (
public RemoteE,'ellf(Ohjecr source. long el·entfD.
long seqNum. MarshafledObject handback)
puNic Object gel Source (j { .. .}
puNic tong get[D() {.. .}
puhtic long gerSequenceNwnber(} (..
puhtic MarshattedObject gcrRegisJr(l!ionObjecl() { .. J
The first argument of the constructor is a remote object. Notifications inform li:;reners
that an event has occurred but the listeners are responsible for obtaining further details.
page 192. 194
5.16 Suggest a design for a notification mailbox ~en'ice which is intended (0 store
nOtifications on behalf of multiple subscribers. allo\\-ing subscribers 10 specify when
they require nOlifications!O be delivered. Explain how subscribers (hat are not always
active can make use of the sen'ice yOll describe. How will the ~er\ ice deal with
subscribers that crash while they ha\'c delivery wmed on'? puge 192
5,i7 Explain how a forwarding observer may be used to enhance the rdiability and
performance of objects of interest in an e\ ent ~cf\·ice. page 191
:'.18 Suggest ways in which observt:!rs can be med to improve the rcliabilit> or performance
of your solution to Exercise 5.15. page 191

(i) if it is single-threaded. and

(ii) if it has twO threads that can make reque",l., concurrently on a ~ingle processor.
'lou can ignore context-switching times. Is there a need for asynchronous RPC if elien,
and server processes arc threaded': page 18()

513 Design a remote object table that can support di~triblJ(ed garbage collection as well as
translating bet\veen local and remote object references. Giye an example involying
sewral remote objects and proxies at various site<' to illustrate the use of the table. 5110\\
the changes in the table when an in\'ocation cau~es a new proxy to be created. Then show
Ihe changes in the table when one of the proxies becomes unreachable. page J81