IS473 Distributed Systems

CHAPTER 5

Distributed Objects & Remote

Invocation
 OUTLINE

Applications

This
chapter RMI, RPC, and events

request-reply protocol Middleware

layers
marshalling and external data representation

UDP and TCP

Dr. Almetwally Mostafa 2

 OUTLINE
Distributed Programming Models.

Distributed Module Interfaces.

Distributed Objects Model.

Remote Procedure Call.

Events and Notifications.

Java RMI Case Study.

Dr. Almetwally Mostafa 3
Distributed Programming Models
A distributed programming model is as an abstraction
layer above communication protocols details.
Different Programming models provided by middleware
to support distributed applications include:
Remote Procedure Call (RPC):
Client programs call procedures in server programs running in
separate remote hosts but in the same way as local procedure
call.
Remote Method Invocation (RMI):
Client objects may invoke methods of remote objects residing in
another process running on another host also in the same way as
local method invocation.
Event-based processing and event notification:
The behavior of the system is driven by events, which represent
local state changes within objects.
Objects receive notifications of events at other objects in which
they have registered interest.
Dr. Almetwally Mostafa 4
Distributed Programming Models
Middleware is the provision of transparency and
heterogeneity challenges:
Location transparency:
RMI and RPC invoked without knowledge of the location of invoked
method/procedure.
Transport protocol transparency:
e.g., request/reply protocol used to implement RPC can use either
transport protocols (UDP or TCP).
Transparency of computer hardware and operating system:
e.g., use of external data representations.
Transparency of programming language used
e.g., by use of programming language independent Interface Definition
Languages, such as CORBA IDL.
Dr. Almetwally Mostafa 5
Distributed Module
Interfaces
Allow interaction between modules of distributed programs.
Specify procedures and variables that can be accessed from
other modules.
Modules are implemented to hide all information about
them except the available through their interfaces.
Module implementation can be changed without affecting its users.
Specifics for interfaces in distributed systems:
No direct access to remote variables:
Use message passing mechanism to transmit data variables.
Local parameter passing mechanisms (by value, by reference) not
applicable to remote invocations.
Specify input or output as parameters attribute.
Input parameters are transmitted with request message and output
parameters are transmitted with reply message.
Pointers are not valid in remote parameter passing.

Dr. Almetwally Mostafa 6

Distributed Module
Interfaces
RPC and RMI interfaces are often seen as:
Service interface (in client/server model for RPC)
Each server provides a set of procedures available for use by
clients
Defining the types of input and output arguments for each
procedure.
Remote interface (in distributed object model for RMI)
Specify the methods of an object that can be invoked by
objects in other processes.
Defining the types of input and output arguments for each
method.
Methods can receive objects or object references (not
pointers) as arguments and may return objects as results.

Dr. Almetwally Mostafa 7

Distributed Interface Definition
Language-specific approach:
The RMI/RPC mechanism is integrated with a particular
programming language if its notation can be used to define
the interfaces and deal with input and output parameters.
Allows the distributed applications programmers to use a
single language for local and remote invocation.
Example: Java RMI.
Interface definition language approach:
Allows objects implemented in different languages to invoke
useful objects implemented in one another.
Uses a general IDL notation for defining interfaces including
input and output parameters with their types.
Example: CORBA IDL.
Dr. Almetwally Mostafa 8
Distributed Objects Model
The logical partition of object-based programs into objects is
naturally extended by the physical distribution of objects into
different processes or computers in a distributed system.
Distributed object systems adopt the client-server architecture:
Objects are managed by servers and their clients invoke their methods using
remote method invocation.
The clients RMI request is sent in a message to the server managing the
invoked method object.
The method of the object at the server is executed and its result is returned
to the client in another message.
Objects in servers are allowed to become clients of objects in other servers.
Distributed objects can be replicated and migrated to obtain the
benefits of fault tolerance, enhanced performance and
availability.
Having client and server objects in different processes enforces
encapsulation due to concurrency and heterogeneity of RMI calls.

Dr. Almetwally Mostafa 9

Distributed Objects Model

C
al
loc
c ation
invo lo E
remote inv cal
oca
tio
invocation n
F
B remo
A
loc invo te
catio
inv a n
oca l
tio
n D

Remote and local method

invocations
Dr. Almetwally Mostafa 10
Distributed Objects Model
Each process contains a collection of objects, some of
which can receive both local and remote invocations and
others can receive only local invocations.
Objects that can receive remote invocations are called
remote objects.
Other objects need to know the remote object reference in
another process in order to invoke its methods.
A remote object reference is an identifier that can be used through
a distributed system to refer to a particular unique remote object.
Every remote object has a remote interface to specify
which of its methods can be invoked remotely.
Objects in other processes can invoke only the methods that
belong to the remote interface of the remote object.
Local objects can invoke the methods in the remote interface as
well as other methods of the remote object.

Dr. Almetwally Mostafa 11

Distributed Objects Model

remoteobject

Data

m1 m4

{
implementation
m5
m2
remote of methods m6
interface m3

A remote object and its remote

interface
Dr. Almetwally Mostafa 12
Distributed Objects Model
Design Issues
Although local invocations are executed exactly once, remote
invocations cannot achieve this. Why not?
RMI usually applied via request/reply protocol which can
suffer from many types of failure:
Message omission and duplication can occur if implemented over UDP.
Process failures (crash or arbitrary) are also possible.
Therefore, different choices of fault-tolerance measures can
be applied:
Retransmit request message until a reply is received or the server is
assumed to be failed
Filter out duplicate requests at the server if retransmit is used.
Re-execute the operation when retransmitted request arrives or result
retransmission (requires keeping a history at the server).
Combinations of fault-tolerance choices lead to a variety of
invocation semantics for the reliability of remote invocation.

Dr. Almetwally Mostafa 13

Distributed Objects Model
Design Issues

Faulttolerancemeasures Invocation
semantics

Retransmitrequest Duplicate Reexecuteprocedure

message filtering orretransmitreply
No Notapplicable Notapplicable Maybe

Yes No Reexecuteoperation Atleastonce

Yes Yes Retransmitreply Atmostonce

Invocation semantics
Dr. Almetwally Mostafa 14
Distributed Objects Model
Design Issues
Maybe invocation semantics:
No fault-tolerance measure is applied.
The invoker cannot tell if a remote method has been executed or not.
Suffer from the following types of failure:
Omission failures if invocation or result message is lost.
Crash failures if the server containing the remote object fails.
Useful only for application accepting occasional failed invocations.
At-least-once invocation semantics:
Uses only retransmission of request messages masks omission
failures.
The invoker receives either a result (after at least one execution) or
an exception informing no result was received.
Suffer from the following types of failure:
Crash failure if the server containing the remote object fails.
Arbitrary failures when re-execute the method more than once which
causing wrong values to stored or returned (non-idempotent operations).
Applicable only if all the remote methods are idempotent operations.
Dr. Almetwally Mostafa 15
Distributed Objects Model
Design Issues
At-most-once invocation semantics:
Uses all the fault-tolerance measures.
The invoker receives either a result (after exactly one execution)
or an exception informing no result was received.
Prevents arbitrary failures by ensuring that a method is never
executed more than once for the same RMI.

CORBA and Java uses at-most-once invocation semantics.

COBRA allows maybe invocation semantics to be
requested for methods without results.
Sun RPC provides at-last-once call semantics.

Dr. Almetwally Mostafa 16

Distributed Objects Model
RMI Implementation
Several separate objects and modules are
involved to achieve a remote method invocation:
Communication modules:
Responsible for providing a specified invocation semantics.
Carry out the request-reply protocol to transmit request
and reply messages between the cooperating server and
client.
Use only the first three items of the request and reply
messages: message type, request id, and the invoked
remote object reference.
Select the dispatcher software for the invoked object class
in the server.
Dr. Almetwally Mostafa 17
Distributed Objects Model
RMI Implementation

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

The proxy and skeleton role in remote method

invocation
Dr. Almetwally Mostafa 18
Distributed Objects Model
RMI Implementation
Remote reference modules:
Translate between local and remote object references and
create remote object references.
Have a remote object table in each process to support the
translation.
An entry for all the remote objects held by the server in its table.
An entry for each local proxy held by the client in its table.
Create a remote object reference and add it to the table
when a remote object is passed in a request or a replay
message for the first time.
Translate the remote object reference to the
corresponding local object reference which refer either to
a remote object (in the server) or to a proxy (in the
client).
Dr. Almetwally Mostafa 19
Distributed Objects Model
RMI Implementation
RMI Software:
Proxy:
Make remote method invocation transparent to clients by behaving like
a local object to the invoker.
Forward the call in a message to the remote object and hiding all in-
between operations (send, receive, marshalling, and unmarshalling)
from the client.
A client has one proxy for each remote object to hold its remote
reference and implement the methods in its remote interface.
Marshal a reference to the target object, its own methodId and its
arguments into a request message and send it to the target then await
the reply message to unmarshal it and return the result to the invoker.
Dispatcher:
A server has one dispatcher for each class representing a remote
object.
Receive the request message from the communication module and use
the methodId to select the appropriate method in the skeleton and
passing on the request message.

Dr. Almetwally Mostafa 20

Distributed Objects Model
RMI Implementation
RMI Software: (cont.)
Skeleton:
Each class representing a remote object has a skeleton in the
server to implement each method in the remote interface.
Unmarshal the argument in the request message and invoke the
corresponding method in the remote object.
Await the invocation to complete to marshal the result in the reply
message to the client proxys method.
The classes of the proxy, skeleton, and dispatcher used in RMI
are generated automatically by an interface complier.
The server program contains the classes for the dispatchers
and skeletons together with the implementations of the
classes of all remote objects that it supports servant classes.
The client program contains the classes of the proxies for all
the remote objects that it will invoke and use a binder to look
up remote object references.
Dr. Almetwally Mostafa 21
 Distributed Objects Model
Distributed Garbage Collection
Free resources occupied by objects that have no more
reference to it in the system.
Work in cooperation with the local garbage collector in each
process in the system.
Java Distributed Garbage Collection algorithm:
Each server maintains a list of clients that hold remote object
references for each of its remote objects.
When a client C first receives a remote reference to a particular
remote object X, it makes an addRef(X) invocation to the server of
that remote object and then the server adds C to the list of object X.
When a client Cs garbage collector notices that a proxy for a remote
object X is no longer referenced, it sends removeRef(X) invocation to
the corresponding server which deletes C from the list of object X.
When the list of a remote object X is empty and there are no local
references to it, the servers local garbage collector collect resources
held by the object X.

Dr. Almetwally Mostafa 22

 Distributed Objects Model
Distributed Garbage Collection
Java algorithm fault tolerance:
Carried out by request/reply communication with at-most-once
invocation semantics between the remote reference modules in
processes.
Toleration of communication failures:
addRef and removeRef are indempotent.
If addRef(X) returns exception, then client will not instantiate proxy
but will send removeRef(X).
Effect of removeRef(X) is correct no matter whether addRef(X)
succeeded or not.
Failure of removeRef(X) is masked by the use of leases.
Leases
Servers lease their objects to clients for limited periods of time,
starting with addRef.
Helps tolerate failures of removeRef as well as client failures.
Avoids problem of having to maintain lists of remote object references
if all object references are handled through leases.
Dr. Almetwally Mostafa 23
Remote Procedure Call (RPC)
Very similar to a remote method invocation
A client process calls a procedure in a server process.
Servers may be clients of other servers to allow chains of RPCs.
Implemented to have one of the choices of invocation semantics.
Implemented over a request-reply protocol .
The contents of request and reply messages are the same as
RMI except that the object reference field is omitted.
The supported software is similar except that no remote
reference modules are required and client proxies and server
skeletons are replaced by client and server stub procedures.
The service interface of the server defines the
procedures that are available for calling remotely.
The client and server stub procedures and the dispatcher
are generated by an interface compiler from the
definition of the service interface.
Dr. Almetwally Mostafa 24
Remote Procedure Call (RPC)

client process server process

Request

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

Role of client and server stub procedures in

RPC
Dr. Almetwally Mostafa 25
Events and Notifications
Distributed event-based systems allowing multiple objects at
different locations to be notified of an event occurrence at a
particular object.
The publish-subscribe paradigm is used:
An object generating events publishes the list of events available for
observation by other objects.
Objects requiring notifications subscribes to the notification service at
an object offering notification for this particular event through its
publication list.
When a publisher experiences an event, subscribers that
expressed an interest in that type of event will receive
notifications.
Events and notifications can be used in a wide variety of
different applications:
A piece of equipment or an electronically tagged book is at new
location.
A client has entered participation in a collaborative work environment.
An electronic document has been modified.
Dr. Almetwally Mostafa 26
Events and Notifications
Dealing Room System
Allow dealers using computer to see the latest information
about the market prices of the stocks.
The market price for a single named stock is represented by an object
with several instance variables.
The information is arrived from different external sources in the form
of updates to some or all instance variables of the stock objects and
collected by information providers.
Dealers are interested only in their specialist stocks.
Modeled by processes with two different tasks:
An information provider process continuously receives information
from a single external source to apply it to the appropriate stock
objects as an event and notifies all the dealers subscribed to the
corresponding stock.
A dealer process creates a local object to represent each named stock
to subscribe the stock object at the relevant information provider and
receive all information sent in notifications to display it to the user.
Dr. Almetwally Mostafa 27
Events and Notifications
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

Dr. Almetwally Mostafa 28

Events and Notifications
Event Types
An event source can generate events of one or more
different types.
Each event has attributes to specify information about that
event: the name of object generated it, the operation, its
parameters and the time.
Types and attributes are used in subscribing to events and in
notifications.
Whenever an event of a specific type that matches the
attributes occurs, the interested parties will be notified.
In dealing room system example:
There is one type of event the arrival of an update to a stock.
The attributes might specify the name of a stock, its current price,
and latest rice or fall.
Dealers may specify the interesting in all the events of a particular
stock.
Dr. Almetwally Mostafa 29