CS 843 - Distributed Computing Systems

Chapter 5: Distributed Objects and Remote

Invocation
Chin-Chih Chang, [email protected]

From Coulouris, Dollimore and Kindberg

Distributed Systems:
Concepts and Design
Edition 3, Addison-Wesley 2001
Distributed Objects and Remote Invocation

Topics covered in this chapter:

Communication between distributed objects
Remote procedure call
Events and notification
Java RMI
What are issues in distributing objects?
How can we identify objects?
What is involved in invoking a method implemented by the
class?
o What methods are available?
o How can we pass parameters and get results?
Can we track events in a distributed system?
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Programming Models for Distributed
Application
Remote procedure call client calls the
procedures in a server program that is running in
a different process
Remote method invocation (RMI) an object in
one process can invoke methods of objects in
another process
Event notification objects receive notification of
events at other objects for which they have
registered
These mechanism must be location-transparent.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Role of Middleware

Middleware Roles
provide high-level abstractions such as RMI
enable location transparency
free from specifics of
ocommunication protocols
ooperating systems and communication
hardware
interoperability

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.1
Middleware layers

Applications

RMI, RPC and events

Middleware
Request reply protocol layers

External data representation

Operating System

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Interfaces
Interface skeleton of public class
Interaction specification
useful abstraction that removes dependencies on internal
details
examples
o procedure interface
o class interface
o module interface
Distributed system interfaces
What is the main difference from single processor
situation?
o processes at different nodes
o can only pass accessible information
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Service Interface (RPC)

Service interface
specifies set of procedures available to client
input and output parameters
Remote Procedure Call
o arguments are marshaled
o marshaled packet sent to server
o server unmarshals packet, performs procedure, and
sends marshaled return packet to client
o client unmarshals the return
o all the details are transparent

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Remote Interface (RMI)

Remote interface
specifies methods of an object available for remote
invocation
input and output parameters may be objects
Remote Method Invocation
o communication actual arguments marshaled and sent
to server
o server unmarshals packet, performs procedure, and
sends marshaled return packet to caller
o client unmarshals return packet
o common format definition for how to pass objects (e.g.,
CORBA IDL or Java RMI)
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Interface Definition Language

Interface Definition Language

notation for language independent interfaces
o specify type and
o kind of parameters
examples
o CORBA IDL for RMI
o Sun XDR for RPC
o DCOM IDL
IDL compiler allows interoperability

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
 CORBA IDL Example
struct Person {
string name; Figure 5.2
CORBA has a struct string place;
long year; remote interface
};
interface PersonList { remote interface defines
readonly attribute string listname;
methods for RMI
void addPerson(in Person p) ;
void getPerson(in string name, out Person p);
long number();
};
parameters are in, out or inout
Remote interface:
specifies the methods of an object available for remote invocation
an interface definition language (or IDL) is used to specify remote
interfaces. E.g. the above in CORBA IDL.
Java RMI would have a class for Person, but CORBA has a struct
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

Addison-Wesley Publishers 2000
The Object Model

An object encapsulates encapsulates both data and

methods.
Objects can be accessed via object references.
An interface provides a definition of the signatures
of a set of methods.
Actions are performed by method invocations.
The state of receiver may be changed.
Further invocations of methods on other objects may take
place.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
The Object Model

Exceptions may be thrown to caller when an error

occurs.
Garbage collection frees the space occupied by
objects when they are no longer needed.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
The Distributed Objects Model

Remote method invocation Method invocations

between objects in different processes, whether in
the same computer of not.
Local method invocation Method invocations
between objects in the same process.
Remote object Objects that can receive remote
invocations.
Remote and local method invocations are shown in
Figure 5.3.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Distributed Object Model
Figure 5.3

remote local C
invocation invocation local E
remote
invocation invocation F
B local
A
invocation D

each process contains objects, some of which can receive remote

invocations, others only local invocations
those that can receive remote invocations are called remote objects
objects need to know the remote object reference of an object in another
process in order to invoke its methods. How do they get it?
the remote interface specifies which methods can be invoked remotely

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

Addison-Wesley Publishers 2000
Distributed Object Model

Remote object reference

An object must have the remote object reference of an
object in order to do remote invocation of an object
Remote object references may be passed as input
arguments or returned as output arguments
Remote interface
Objects in other processes can invoke only the methods
that belong to its remote interface (Figure 5.4).
CORBA uses IDL to specify remote interface
JAVA extends interface by the Remote keyword.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.4
A remote object and its remote interface

remoteobject

Data
remote
interface
m1 implementation m4

{ m2
m3 of methods
m5
m6

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Design Issues for RMI

Two important issues in making RMI natural

extension of local method: (These problems wont
occur in the local invocation.)
Number of times of invocations are invoked in response
to a single remote invocation
Level of location transparency
Exactly once invocation semantics - Every
method is executed exactly once. (Ideal situation)

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Invocation Semantics Properties

Maybe invocation semantics:

The invoker can not determine whether or not the remote
method has been executed.
Types of failures:
o Omission failures if the invocation or result message is
lost.
o Crash failures when the server containing the remote
object fails.
Useful for applications where occasional failed invocation
are acceptable.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Invocation Semantics Properties
At-least-once invocation semantics:
The invoker either receives a result (in which case the
user knows the method was executed at least once) or an
exception.
Types of failures:
o Retransmitting request masks omission failures.
o Crash failures when the server containing the remote
object fails.
o Arbitrary failure when the remote method is invoked
more than once, wrong values are stored or returned.
An idempotent operation that can be performed
repeatedly with the same effect can be a solution.
Useful if the objects in a server can be designed to have
idempotent operations.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Invocation Semantics Properties
At-most-once invocation semantics:
The invoker either receives a result (and the user knows
the the method was executed exactly at most once) or an
exception.
All fault tolerance methods executed.
Omission failures can be eliminated by retransmitting
request.
Arbitrary failures can be prevented by ensuring that no
method is executed more than once.
JAVA RMI and CORBA use at-most-once semantics.
CORBA also maybe semantics for methods that do
not return results. SUNRPC provides at-least-once
semantics.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Invocation Semantics

To provide a more reliable request-reply

protocol, these fault-tolerant measures can be
employed:
Retry request message: whether to retransmit the
request message until either a reply is received or the
server is assumed to have failed.
Duplicate filtering: when retransmissions are used,
whether to filter out duplicate requests at the server.
Retransmission of results: whether to keep a history of
result messages to enable lost results to be retransmitted
without re-executing the operations at the server.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Invocation Semantics

Combinations of these measures lead to a variety of

possible semantics for the reliability of remote
invocations.
Figure 5.5 shows the measures, with corresponding
names for the invocation semantics that they
produce.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Invocation Semantics

Local invocations are executed exactly once

Remote invocations cannot achieve this. Why not? :
The Request-reply protocol can apply fault-tolerance
measure.
Figure 5.5 Fault tolerance measures Invocation
semantics

Retransmit request Duplicate Re-execute procedure

message filtering or retransmit reply
No Not applicable Not applicable Maybe
Yes No Re-execute procedure At-least-once

Yes Yes Retransmit reply At-most-once

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

Addison-Wesley Publishers 2000
(Location) Transparency Issues

Goal is to make a remote invocation as similar as

possible a local invocation.
Issues (Differences from the local invocation)
Syntax may be made identical but behavioral differences
exists. The cause could be failure and latency.
Interface specification
o Exceptions and exception handling are needed.
o Different invocation semantics can be employed.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Implementation of RMI

Figure 5.6 shows an object A invokes a method in a

remote object B.
Communication module:
Request-Reply Protocol
Responsible for providing selected invocation semantics
The server selects the dispatcher for the class of the
object to be invoked.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
 The Architecture of Remote Method
Invocation
Figure 5.6

client server
remote
object A proxy for B skeleton
object B
Request & dispatcher
for Bs class

Reply

Remote Communication Communication Remote reference

reference module module module module

Proxy - makes RMI transparent to client. carriesClass out Request-implements

remote interface. Marshals requests andprotocolunmarshals RMI software - between
reply
results. Forwards request. application level objects
translates
Skeleton - between
implementslocal and remote
methods in remote objectinterface.
and communication and
references
Unmarshals and creates
requests remote
and marshals object
Dispatcher - gets request from communication module and results. Invokes
references.
methodmethod Uses
in remote remote
object. object table remote reference modules

invokes in skeleton (using
Instructors methodID
Guide for Coulouris, in message).
Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Remote Reference Module

Responsibilities
translation between local and remote object references
o remote object table
- entry for each remote object held by process
- entry for each local proxy
o arriving remote object reference - creation of remote
object references
creation of remote object references
o need to pass a remote object - look up in remote object
table (create new remote object reference and add
entry if necessary)
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Software

Proxy - provides remote invocation transparency

marshal arguments, unmarshal results, send and receive
messages
Dispatcher - handles transfer of requests to correct
method
receive requests, select correct method, and pass on
request message
Skeleton - implements methods of remote interface
unmarshal arguments from request, invoke the method of
the remote object, and marshal the results

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Server and Client Programs

Server
classes for dispatchers, skeletons and remote objects
initialization section for creating some remote objects
registration of remote objects with the binder
Client
classes for proxies of all remote objects
binder to look up remote object references
cannot create remote objects by directly calling
constructors - provide factory methods instead

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Binder and Server Threads

A binder in a distributed system is a separate

service that maintains a table containing mappings
from textual names to remote object references.
Server threads
sometimes implemented so that remote invocation causes
a new thread to be created to handle the call
server with several remote objects might also allocate
separate threads to handle each object
o What are the advantages/disadvantages of each
approach?
o What other threading organizations could be used?
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Binder and Server Threads

Activation of remote objects

A remote object is described as active when it is a running
process.
A remote object is described as passive when it can be
made active if requested.
An object that can live between activations of
processes is called a persistent object.
A location service helps clients to locate remote
objects from their remote references.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Distributed Garbage Collection

Aim - recover memory if no reference to an object

exist. If there is a reference object should still exists.
Java distributed algorithm - based on reference
counting
The distributed garbage collector works in
cooperation with the local garbage collector.
Each server has a table (B.holders) that maintains list of
references to an object.
When the client C first receives a reference to an object B,
it invokes addRef(B) and then creates a proxy. The server
adds C to the remote object holder B.holders.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Distributed Garbage Collection

The distributed garbage collection (continued):

When remote object B is no longer reachable, it deletes
the proxy and invokes removeRef(B).
When B.holders is empty, the server reclaim the space
occupied by B.
Leases in Jini
To avoid complicated protocols to discover whether a
resource are still used, the resource is leased for use for a
period of time.
An object representing a lease implements the Lease
interface.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Remote Procedure Call Basics

Problems with sockets

The read/write (input/output) mechanism is used
in socket programming.
Socket programming is different from procedure
calls which we usually use.
To make distributed computing transparent from
locations, input/output is not the best way.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Remote Procedure Call Basics

A procedure call is a standard abstraction in local

computation.
Procedure calls are extended to distributed
computation in Remote Procedure Call (RPC) as
shown in Figure 5.7.
A caller invokes execution of procedure in the
callee via the local stub procedure.
The implicit network programming hides all
network I/O code from the programmer.
Objectives are simplicity and ease of use.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.7
Role of client and server stub procedures in RPC

client process server process

Request

Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module dispatcher

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Remote Procedure Call Basics

The concept is to provide a transparent mechanism

that enables the user to utilize remote services
through standard procedure calls.
Client sends request, then blocks until a remote
server sends a response (reply).
Advantages: user may be unaware of remote
implementation (handled in a stub in library); uses
standard mechanism.
Disadvantages: prone to failure of components and
network; different address spaces; separate process
lifetimes.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Remote Procedure Call Basics

Differences with respect to message passing:

Message passing systems are peer-to-peer while RPC is
more master/slave.
In message passing the calling process creates the
message while in RPC the system create the message.
Semantics of RPC:
Caller blocks.
Caller may send arguments to remote procedure.
Callee may return results.
Caller and callee access different address spaces.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Sun RPC

It is designed for client-server communication over

Sun NFS network file system.
UDP or TCP can be used. If UDP is used, the
message length is restricted to 64 KB, but 8 - 9 KB
in practice.
The Sun XDR is originally intended for external data
representation.
Valid data types supported by XDR include int,
unsigned int, long, structure, fixed array, string
(null terminated char *), binary encoded data (for
other data types such as lists).
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Interface Definition Language

The notation is rather primitive compared to CORBA

IDL or JAVA as shown in Figure 5.8.
Instead of no interface definition, a program
number and a version number are supplied.
The procedure number is used as a procedure
definition.
Single input parameter and output result are being
passed.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.8
Files interface in Sun XDR

const MAX = 1000;

typedef int FileIdentifier;
typedef int FilePointer;
typedef int Length; struct readargs {
struct Data { FileIdentifier f;
int length; FilePointer position;
char buffer[MAX]; Length length;
}; };
struct writeargs {
FileIdentifier f; program FILEREADWRITE {
FilePointer position; version VERSION {
Data data; void WRITE(writeargs)=1; 1
}; Data READ(readargs)=2; 2
}=2;
} = 9999;

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Sun RPC
The interface compiler rpcgen can be used to
generate the following from interface definition.
client stub procedures
server main procedure, dispatcher and server stub
procedures
XDR marshalling and unmarshalling procedures used
by dispatcher and client, server stub procedures.
Binding:
portmapper records program number, version number,
and port number.
If there are multiple instance running on different
machines, clients make multicast remote procedure calls
by broadcasting them to all the port mappers.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC Interface Compiler

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Sun RPC

Authentication:
Additional fields are provided in the request-reply
message.
Server program should check the authentication and then
execute.
Different authentication protocols can be supported - none,
UNIX style, shared key, Kerberos style.
A field in RPC header indicates which style is used.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Example (Sun RPC)

long sum(long) example

client localhost 10
result: 55
Need RPC specification file (sum.x)
defines procedure name, arguments & results
Run (interface compiler) rpcgen sum.x
generates sum.h, sum_clnt.c, sum_xdr.c, sum_svc.c
sum_clnt.c & sum_svc.c: Stub routines for client & server
sum_xdr.c: XDR (External Data Representation) code
takes care of data type conversions

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC IDL File (sum.x)

struct sum_in {
long arg1;
};
struct sum_out {
long res1;
};
program SUM_PROG {
version SUM_VERS {
sum_out SUMPROC(sum_in) = 1; /* procedure number = 1*/
} = 1; /* version number = 1 */
} = 0x32123000; /* program number */

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Example (Sun RPC)

Program-number is usually assigned as follows:

0x00000000 - 0x1fffffff defined by SUN
0x20000000 - 0x3fffffff defined by user
0x40000000 - 0x5fffffff transient
0x60000000 - 0xffffffff reserved

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC Client Code (rsum.c)
#include ''sum.h''
main(int argc, char* argv[]) {
CLIENT* cl; sum_in in; sum_out *outp;
// create RPC client handle; need to know server's address
cl = clnt_create(argv[1], SUM_PROG, SUM_VERS, ''tcp'');
in.arg1 = atol(argv[2]); // number to be squared
// Call RPC; note convention of RPC function naming
if ( (outp = sumproc_1(&in, cl)) == NULL)
err_quit(''%s'', clnt_sperror(cl, argv[1]);
printf(''result: %ld\n'', outp->res1);
}
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC Server Code (sum_serv.c)

#include "sum.h"
sum_out* sumproc_1_svc (sum_in *inp, struct svc_req *rqstp)
{ // server function has different name than client call
static sum_out out; // why is this static?
int i;
out.res1 = inp->arg1;
for (i = inp->arg1 - 1; i > 0; i--)
out.res1 += i;
return(&out);
}
// server's main() is generated by rpcgen

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Compilation Linking

rpcgen sum.x
cc -c rsum.c -o rsum.o
cc -c sum_clnt.c -o sum_clnt.o
cc -c sum_xdr.c -o sum_xdr.o
cc -o client rsum.o sum_clnt.o sum_xdr.o
cc -c sum_serv.c -o sum_serv.o
cc -c sum_svc.c -o sum_svc.o
cc -o server sum_serv.o sum_svc.o sum_xdr.o

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Internal Details of Sun RPC
Initialization
Server runs: register RPC with port mapper on server host
(rpcinfo p)
Client runs: clnt_create contacts server's port mapper
and establishes TCP connection with server (or UDP
socket)
Client
Client calls local procedure (client stub: sumproc_1), that
is generated by rpcgen. Client stub packages arguments,
puts them in standard format (XDR), and prepares network
messages (marshaling).
Network messages are sent to remote system by client
stub.
Network transfer is accomplished with TCP or UDP.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Internal Details of Sun RPC

Server
Server stub (generated by rpcgen) unmarshals arguments
from network messages. Server stub executes local
procedure (sumproc_1_svc) passing arguments received
from network messages.
When server procedure is finished, it returns to server stub
with return values.
Server stub converts return values (XDR), marshals them
into network messages, and sends them back to client
Back to Client
Client stub reads network messages from kernel
Client stub returns results to client function
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Details of RPC

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC Issues

Uniform call semantics - Calling semantics must

be same whether procedure is implemented locally
or remotely.
Exactly once: It is hard to achieve in practice.
At most once: It requests RPC only once (no reply may
mean that no execution tooks place)
At least once: It keeps requesting RPC until valid
response arrives at client.
RPC is inappropriate for nonidempotent operations.
Type checking - Level of static type checking used
for local calls should be the same as that for remote
calls.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC Issues

Full parameter functionality - All basic data types

should be allowed; this includes but is not limited to:
primitive types, structured types, and user defined
types.
Concurrency control and exception handling -
Although not a direct portion of RPC, the
programming language that provide RPC must
support these services.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RPC Issues

Distributed binding - Programming language must

be able to compile, bind and load distributed
program onto the network
Orphan Computations
This involves recovery from failed RPC
It can use extermination to find and abort orphan
computations.
It can use expiration to terminate a computation that
exceeds its expected lifetime.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

The idea behind the use of events is that one object

can react to a change occurring in another object.
The actions done by the user are seen as events
that cause state changes in objects.
The objects are notified whenever the state
changes.
Local event model can be extended to distributed
event-based systems by using the publish-
subscribe paradigm.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

In publish-subscribe paradigm
An object that has event publishes.
Those that have interest subscribe.
Objects that represent events are called
notifications.
Distributed event-based systems have two main
characteristics:
Heterogeneous Event-based systems can be used to
connect heterogeneous components in the Internet.
Asynchronous Notification are sent asynchronously by
event-generating objects to those subscribers.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

A dealing room system could be modeled by

processes with two different tasks (Figure 5.9):
An information provider process continuously receives
new trading information from a single external source and
applies to the appropriate stock objects.
A dealer process creates an object to represent each
named stock that the user asks to have displayed.
An event source can generate events of one more
different types. Each event has attributes that
specify information about that event.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.9
Dealing room system

Dealers computer External Dealers computer

source

Dealer Notification Notification Dealer

Notification Information
provider Notification

Notification
Notification
Notification
Dealers computer Dealers computer
Notification
Information
provider
Notification
Dealer Notification
Dealer
External
source

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

The architecture of distributed event notification

specifies the roles of participants as in Fig. 5.10:
It is designed in a way that publishers work
independently from subscribers.
Event service maintains a database of published
events and of subscribers interests.
The roles of the participants are:
Object of Interest This is an object experiences
changes of state, as a result of its operations being
invoked.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

The roles of the participants are (continued):

Event An event occurs at an object of interest as the
result of the completion of a method invocation.
Notification A notification is an object that contains
information about an event.
Subscriber A subscriber is an object that has
subscribed to some type of events in another object.
Observer objects The main purpose of an observer
is to separate an object of interest from its subscribers.
Publisher This is an object that declares that it will
generate notifications of particular types of event.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

Figure 5.10 shows three cases:

1. An object of interest inside the event service sends
notification directly to the subscribers.
2. An object of interest inside the event service sends
notification via the observer to the subscribers.
3. The observer queries the object of interest outside the
event service and sends notifications to the
subscribers.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.10
Architecture for distributed event notification

Event service
object of interest subscriber

1. notification

object of interest observer subscriber

2. notification notification

object of interest observer subscriber

3. notification

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

A variety of delivery semantics can be

employed:
IP multicast protocol information delivery on the
latest state of a player in an Internet game
Reliable multicast protocol information provider /
dealer
Totally ordered multicast - Computer Supported
Cooperative Working (CSCW) environment
Real-time nuclear power station / hospital patient
monitor

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Events and Notifications

Roles for observers the task of processing

notifications can be divided among observers:
Forwarding Observers simply forward notifications
to subscribers.
Filtering of notifications Observers address
notifications to those subscribers who find these
notifications are useful.
Patterns of events Subscribers can specify
patterns of events of interest.
Notification mailboxes A subscriber can set up a
notification mailbox which receives the notification on
behalf of the subscriber.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Jini Distributed Event Specification

Jini network technology is an open spontaneous

network architecture that enables developers to
create network-centric services - whether
implemented in hardware or software - that are
highly adaptive to change.
Jinis distributed events specification allows a
potential subscriber in one Java Virtual
Machine(JVM) to subscribe to and receive
notifications of events in an object of interest in
another JVM.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Jini Distributed Event Specification

Main objects:
Event generators - It is an object that allows other
objects to subscribe to its events and generates
notifications.
Remote event listeners - A remote event listener is an
object that can receive notifications.
Remote events - A remote event is an object that is
passed by value to remote event listeners. It is equivalent
to a notification.
Third party agents - Third party agents may be
interposed between an object of interest and a subscriber.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Interfaces and Classes

Jini events are provided by means of the following

interfaces and classes:
RemoteEventListener - The RemoteEventListener
interface needs to be implemented by any object that
wants to receive a notification of a remote event from
some other object.
RemoteEvent - The base class or superclass for remote
events.
EventRegistration - A utility class for use as a return
value for event-interest registration methods.
For more details, refer to Jini online document.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI

Java RMI extends the Java object model to provide

support for distributed objects in the Java language.
It allows objects to invoke methods on remote objects
using the same syntax as for local invocations.
Type checking applies equally to remote invocations as to
local ones.
The remote invocation is known because
RemoteExceptions has been handled and the remote
object is implemented using the Remote interface.
The semantics of parameter passing differ because
invoker and target are remote from on another.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI

Programming distributed applications in Java RMI is

simple.
It is a single-language system.
The programmer of a remote object must consider its
behavior in a concurrent environment.
The files needed for creating a Java RMI application
are:
A remote interface defines the remote interface provided
by the service. Usually, it is a single line statement
specifies the service function (HelloInterface.java). (An
interface is the skeleton for a public class.)
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI

The files needed for creating a Java RMI application

are (continued):
A remote object implements the remote service. It
contains a constructor and required functions. (Hello.java)
A client that invokes the remote method.
(HelloClient.java)
The server offers the remote service, installs a security
manager and contacts rmiregistry with an instance of the
service under the name of the remote object.
(HelloServer.java)

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
HelloInterface.java

import java.rmi.*;

public interface HelloInterface extends Remote {

public String say(String msg) throws
RemoteException;
}

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Hello.java

import java.rmi.*;
import java.rmi.server.*;
public class Hello extends
UnicastRemoteObject implements HelloInterface {
private String message;

public Hello(String msg) throws RemoteException {

message = msg;
}

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Hello.java (continued)

public String say(String m) throws RemoteException {

// return input message - reversing input and suffixing
// our standard message
return new StringBuffer(m).reverse().toString() + "\n" +
message;
}
}

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
HelloClient.java

import java.rmi.*;

public class HelloClient {

public static void main(String args[]) {
String path = "//localhost/Hello";
try {
if (args.length < 1) {
System.out.println("usage: java HelloClient
<host:port> <string> ... \n");
} else path = "//" + args[0] + "/Hello";
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
HelloClient.java

HelloInterface hello =
(HelloInterface) Naming.lookup(path);
for (int i = 0; i < args.length; ++i)
System.out.println(hello.say(args[i]));
} catch(Exception e) {
System.out.println("HelloClient exception: " + e);
}
}
}
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
HelloServer.java

import java.rmi.*;
import java.rmi.server.*;

public class HelloServer {

public static void main(String args[]) {
// Create and install a security manager
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
try {
Naming.rebind("Hello", new Hello("Hello, world!"));
System.out.println("server is running...");
}
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
HelloServer.java

catch (Exception e) {
System.out.println("Hello server failed:" + e.getMessage());
}
}
}

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI

Compile the code

javac Hello.java HelloClient.java
HelloInterface.java HelloServer.java
Generate stubs for the remote service
(make sure that your classpath contains your current
directory)
rmic Hello
Start the registry (in a separate window or in the
background)
rmiregistry
(be sure to kill this process when you're done)
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI

Start the server in one window or in the background

with the security policy
java -Djava.security.policy=policy HelloServer
or without the security policy
java HelloServer
Run the client in another window
java HelloClient testing

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI Remote Object References
An object must have the remote object reference of
other object in order to do remote invocation of that
object.
Parameter and result passing
Remote object references may be passed as input
arguments or returned as output arguments.
Parameters of a method in Java are input parameters.
Returned result of a method in Java is the single output
parameter.
Objects are serialized to be passed as parameters.
When a remote object reference is returned, it can be
used to invoke remote methods.
Local serializable objects are copied by value.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI Remote Object References

Downloading of classes
Java is designed to allow classes to be downloaded from
one virtual machine to another.
If the recipient of a remote object reference does not
posses the proxy class, its code is downloaded
automatically.
RMIregistry
The RMIregistry is designed to allow is the binder for Java
RMI.
It maintains a table mapping textual, URL-style names to
references to remote objects.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI Remote Object References

Server Program
The server consists of a main method and a servant class
to implement each of its remote interface.
The main method of a server needs to create a security
manager to enable Java security to apply the protection for
an RMI server.
Client Program
Any client program needs to get started by using a binder
to look up a remote reference.
A client can set a security manager and then looks up a
remote object reference.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI Callbacks

Callback refers to server's action in notifying the

client.
Callback Facility - Instead of client polling the
server, the server calls a method in the client when it
is updated.
Details
Client creates a remote object that implements an
interface for the server to call.
The server provides an operation for clients to register
their callbacks.
When an event occurs, the server calls the interested
clients.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Java RMI Callback Issues

Advantages of callback
more efficient than polling
more timely than polling
provides a way for the server to inquire about client status
Disadvantages of callback
may leave server in inconsistent state if client crashes or
exits without notifying server
requires server to make series of synchronous RMI's

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Shared Whiteboard Example

In the RMI and CORBA case studies, we use a

shared whiteboard 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, each of which has been drawn by one of
the users.
The server maintains the current state of a drawing
and it provides operations for clients to:
Add a shape, retrieve a shape or retrieve all the shapes,
Retrieve its version number or the version number of a
shape
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

Addison-Wesley Publishers 2000
Figure 5.11
Java Remote interfaces Shape and ShapeList

Note the interfaces and arguments

GraphicalObject is a class that implements Serializable.

import java.rmi.*; Figure 5.11

import java.util.Vector;
public interface Shape extends Remote {
int getVersion() throws RemoteException;
GraphicalObject getAllState() throws RemoteException;
}
public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g) throws RemoteException;
Vector allShapes() throws RemoteException;
int getVersion() throws RemoteException;

} Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.12
The Naming class of Java RMIregistry

void rebind (String name, Remote obj)

This method is used by a server to register the identifier of a remote object by
name, as shown in Figure 15.13, line 3.
void 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.
void unbind (String name, Remote obj)
This method removes a binding.
Remote lookup(String name)
This method is used by clients to look up a remote object by name, as shown
in Figure 15.15 line 1. A remote object reference is returned.
String [] list()
This method returns an array of Strings containing the names bound in the
registry.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.13
Java class ShapeListServer with main method

import java.rmi.*;
public class ShapeListServer{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
try{
ShapeList aShapeList = new ShapeListServant(); 1
Naming.rebind("Shape List", aShapeList ); 2
System.out.println("ShapeList server ready");
}catch(Exception e) {
System.out.println("ShapeList server main " + e.getMessage());}
}
}

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.14
Java class ShapeListServant implements interface ShapeList

import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
import java.util.Vector;
public class ShapeListServant extends UnicastRemoteObject implements ShapeList {
private Vector theList; // contains the list of Shapes 1
private int version;
public ShapeListServant()throws RemoteException{...}
public Shape newShape(GraphicalObject g) throws RemoteException { 2
version++;
Shape s = new ShapeServant( g, version); 3
theList.addElement(s);
return s;
}
public Vector allShapes()throws RemoteException{...}
public int getVersion() throws RemoteException { ... }
}
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.15
Java client of ShapeList

import java.rmi.*;
import java.rmi.server.*;
import java.util.Vector;
public class ShapeListClient{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
ShapeList aShapeList = null;
try{
aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ; 1
Vector sList = aShapeList.allShapes(); 2
} catch(RemoteException e) {System.out.println(e.getMessage());
}catch(Exception e) {System.out.println("Client: " + e.getMessage());}
}
}

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
Figure 5.16
Classes supporting Java RMI

RemoteObject

RemoteServer

Activatable UnicastRemoteObject

<servant class>

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Addison-Wesley Publishers 2000
RMI Summary

Each object has a (global) remote object reference

and a remote interface that specifies which of its
operations can be invoked remotely.
Local method invocations provide exactly-once
semantics; the best RMI can guarantee is at-most-
once.
Middleware components (proxies, skeletons and
dispatchers) hide details of marshalling, message
passing and object location from programmers.

Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

Addison-Wesley Publishers 2000