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 client’s 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
l
loca
oc a tion
inv lo E
remote inv cal
oca
tion
invocation
F
B remo
A
loca invoc te
ation
inv l
oca
tion
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

remote object

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

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 operation At-least-once

Yes Yes Retransmit reply At-most-once

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 B’s 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 proxy’s 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 C’s 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 server’s 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
Dealer’s computer External Dealer’s computer
source

Dealer Notification Notification Dealer

Notification Information
provider Notification

Notification
Notification
Notification
Dealer’s computer Dealer’s 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