CHAPTER 5

Remote Invocation

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design
Edition 5, © Pearson Education 2005

Dr. Aref Hassan Kurdali

CS 462 - Distributed Systems 1

Middleware layers

2
Introduction

 This chapter is concerned with how processes communicate in a distributed

system.
 Request-reply protocols support the two-way exchange of messages as
encountered in client-server computing and provide direct support for RPC and
RMI.
 RMI (Remote Method Invocation) is a Java-specific technology that allows an
object running in one Java Virtual Machine (JVM) to invoke methods on an object
running in another JVM, possibly on a different physical machine.
 RPC (Remote Procedure Call) is a protocol that allows a program to execute a
procedure (or function) on another address space (e.g., on another server or
machine) as if it were a local procedure.
 CORBA (Common Object Request Broker Architecture) is a standard defined by
the OMG (Object Management Group) that allows distributed objects written in
different programming languages to communicate over a network. CORBA uses an
Object Request Broker (ORB) to facilitate this communication

3
Introduction

 Key Differences

Feature RMI RPC CORBA

Language- Language-
Language Support Java only
independent independent

Paradigm Object-oriented Procedure-oriented Object-oriented

Cross-language, Cross-language,
Communication Java-to-Java only
Cross-platform Cross-platform

Architecture Client-server Client-server Broker-based (ORB)

Simplified for Java Easier but Complex and

Ease of Use
developers language-specific feature-rich
4
Introduction

 Key Similarities
 All three are used for distributed computing,
enabling communication between different
systems across a network.
 All involve some form of method invocation on
remote services, abstracting the underlying
networking.
 RMI, RPC, and CORBA follow the client-server
model.

5
Introduction

 Advantages and Disadvantages Summary

Technology Advantages Disadvantages

• Java-only.
• Tight integration with Java. • Performance overhead due to
RMI Object-oriented communication serialization.
• Limited scalability.
• Language-independent. • No object-oriented support.
RPC •
•
Simple to use.
Abstracts network details
• Manual error handling.
• Limited security features.
• Language and platform • High complexity.
independence. • Performance overhead.
CORBA • Rich features (security, • Decreased popularity in favor
transactions, etc.) of newer technologies 6
Request-reply protocols

 Typical client-server interactions is a request-reply communication that is

synchronous because the client process blocks until the reply arrives
 Asynchronous request-reply communication – an alternative that may be
useful in situations where clients can afford to retrieve replies later.
 The request-reply protocol described here is based on a trio of
communication primitives, doOperation, getRequest and sendReply, as
shown in figure below

7
Request-reply protocols

 The first argument of doOperation is an instance of the class RemoteRef,

which represents references for remote servers.
 The caller of doOperation is blocked until the server performs the
requested operation and transmits a reply message.
 getRequest is used by a server process to acquire service requests, as
shown in the following figure.

8
Request-reply protocols

 The following figure shows the information to be transmitted in a request

message or a reply message.

9
Request-reply protocols
 Message identifiers: communication requires that each message have
a unique message identifier by which it may be referenced. A message
identifier consists of two parts:
 a requestId (makes identifier unique to the sender)
 an identifier for the sender process (makes identifier unique in the distributed system)

 Failure model of the request-reply protocol if

implemented over UDP datagrams:
 Omission failures
 Messages are not guaranteed to be delivered in sender order
 Timeouts
 doOperation uses a timeout. Timeout indicates that doOperation is failed
 doOperation sends the request message repeatedly until either it gets a reply or it is
reasonably sure that the delay is due to lack of response from the server rather than
to lost messages.

10
Request-reply protocols
 Server discards duplicate request messages with the
same request identifier and filters out duplicates.
 History: For servers that require retransmission of
replies without re-execution of operations, a history may
be used.
 Styles of exchange protocols: Three protocols, that
produce differing behaviors in the presence of
communication failures, are used for implementing
various types of request behavior:
1. the request (R) protocol
2. the request-reply (RR) protocol
3. the request-reply-acknowledge reply (RRA) protocol.

11
Request-reply protocols
1. the request (R) protocol:
• The R protocol may be used when there is no value to be returned
from the remote operation and the client requires no confirmation that
the operation has been executed.
• no need to wait for a reply message.
• is implemented over UDP datagrams
2. the request-reply (RR) protocol:
• is useful for most client-server exchanges because it is based on the
request-reply protocol
3. the request-reply-acknowledge reply (RRA) protocol:
• enable the server to discard entries from its history. The arrival of a
requestId in an acknowledgement message will be interpreted as
acknowledging the receipt of all reply messages with lower
requestIds, so the loss of an acknowledgement message is harmless.

12
Request-reply protocols

13
Request-reply protocols
 Use of TCP streams to implement the request-reply
protocol
 The limited length of datagrams (usually 8 kilobytes) may not be regarded
as adequate for use in transparent RMI or RPC systems, since the
arguments or results of procedures may be of any size.
 TCP streams, allowing arguments and results of any size to be transmitted
 TCP ensures that request and reply messages are delivered reliably, so
there is no need for the request-reply protocol to deal with retransmission
of messages and filtering of duplicates or with histories.
 TCP’s flow-control mechanism allows large arguments and results to be
passed without taking special measures to avoid overwhelming the
recipient.
 TCP protocol is chosen for request-reply protocols because it can simplify
their implementation.

14
Request-reply protocols
 Use of HTTP: An example of a request-reply protocol
HTTP is implemented over TCP
It supports a fixed set of methods (GET, PUT,
POST, etc) that are applicable to all of the server’s
resources

15
Remote procedure call (RPC)
 in RPC, procedures on remote machines can be
called as if they are procedures in the local address
space.
 RPC hides important aspects of distribution.

16
Remote procedure call (RPC): Design issues
 Design issues for RPC
1. Programming with interfaces
2. RPC call semantics (refers to the rules and behaviors governing how
RPCs are executed)
3. Transparency

17
Remote procedure call (RPC): Design issues

1. programming with interfaces

• Most modern programming languages provide a means of organizing a
program as a set of modules that can communicate with one another.
Communication between modules can be by means of procedure calls
between modules.
• To control the possible interactions between modules, an explicit
interface is defined for each module.
• The interface of a module specifies the procedures and the variables that
can be accessed from other modules.
• So long as its interface remains the same, the implementation may be
changed without affecting the users of the module.
• In the client-server model, each server provides a set of procedures that
are available for use by clients.
• The term service interface is used to refer to the specification of the
procedures offered by a server, defining the types of the arguments of
each of the procedures.

18
Remote procedure call (RPC): Design issues

1. programming with interfaces

• There are several benefits to programming with interfaces
in distributed systems:
– abstraction offered by the service interface and
need not be aware of implementation details.
– programmers also do not need to know the
programming language or underlying platform
used to implement the service
– implementations can change as long as long as
the interface (the external view) remains the same.
• The figure in the next slide shows a simple example of
CORBA IDL
19
Remote procedure call (RPC): Design issues

1. programming with interfaces

The interface named

PersonList specifies the
methods available for RMI
in a remote object that
implements that interface.
For example, the method
addPerson specifies its
argument as in, meaning
that it is an input argument,
and the method getPerson
that retrieves an instance of
Person by name specifies
its second argument as out,
meaning that it is an output 20
argument.
Remote procedure call (RPC): Design issues

2. RPC call semantics

 doOperation can be implemented in different ways to provide
different delivery guarantees. The main choices are:
 Retry request message: Controls whether to retransmit the
request message until either a reply is received, or the server
is assumed to have failed.
 Duplicate filtering: Controls when retransmissions are used
and whether to filter out duplicate requests at the server. (or
server send reply for each duplicated request)
 Retransmission of results: Controls whether to keep a history
of result messages to enable lost results to be retransmitted
without re-executing the operations at the server

21
Remote procedure call (RPC): Design issues

2. RPC call semantics

 Combinations of the choices lead to a variety of possible
semantics for the reliability of remote invocations as seen by
the invoker:
 Maybe semantics
 At-least-once semantics
 At-most-once semantics

22
Remote procedure call (RPC): Design issues

2. RPC call semantics

23
Remote procedure call (RPC): Design issues

3. Transparency
 Transparency aimed to make remote procedure calls as
much like local procedure calls as possible, with no
distinction in syntax between a local and a remote
procedure call.
 All the necessary calls to marshalling and message-
passing procedures were hidden from the programmer
making the call.
 RPC strives to offer at least location and access
transparency, hiding the physical location of the
(potentially remote) procedure and accessing local and
remote procedures in the same way

24
Remote procedure call (RPC): Implementation
The software components required to implement RPC are shown in below
figure

25
Remote procedure call (RPC): Implementation
 In RPC, a client stub procedure allows a client to invoke functions on a remote
server as if they were local calls. It acts as an intermediary on the client side and
performs the following key tasks:
 Marshaling Data
 Sending the Request
 Receiving the Response
 The dispatcher selects one of the server stub procedures according to the
procedure identifier in the request message.
 In RPC, a server stub procedure acts as an intermediary between the client and
the server to facilitate communication across a network. Here's what it does:
 Receives Requests
 Unmarshals Data
 Calls the actual server-side procedure
 Sends Back the Response
 Communication module operates at a lower level than the stubs, dealing directly
with the network layer for sending and receiving packets.

26
Remote method invocation (RMI)
 RMI is closely related to RPC but extended into the world of
distributed objects.
 In RMI, a calling object can invoke a method in a potentially
remote object.
 Similarities between RMI and RPC:
 Both support programming with interfaces.
 Both constructed on top of request-reply.
 Both offer a range of call semantics such as:
 at-least-once
 at-most-once
 both offer a similar level of transparency.

27
Remote method invocation (RMI)
 Differences between RMI and RPC:
 RMI has full expressive power of object-oriented
programming
 use of objects, classes and inheritance
 object oriented design methodologies and associated tools
 All objects in an RMI-based system have unique object
references (independent of they are local or remote)
 object references can also be passed as parameters, thus
offering significantly richer parameter-passing semantics than
in RPC

28
Remote method invocation (RMI): Design Issues

The object mode

Accessibility: in a distributed object system, an object’s data should be
accessible only via its methods.
Object references: To invoke a method in an object, the object reference and
method name should be given.
Interfaces: An interface provides a definition of the signatures of a set of
methods without specifying their implementation.
Actions: refers to the methods (behaviors) that objects can perform.
Exceptions: A block of code may be defined to throw an exception whenever
particular unexpected conditions or errors arise. Exception provides a clean way
to deal with error conditions without complicating the code (in java: try…catch).
Garbage collection: is freeing the space occupied by objects when they are no
longer needed. When a language (for example, C++) does not support garbage
collection, the programmer must cope with the freeing of space allocated to
objects. This can be a major source of errors.

29
Remote method invocation (RMI): Design Issues

Distributed objects
The invocation is carried out by executing a method of the object at the
server and the result is returned to the client in another message.
Chains of related invocations: objects in servers are allowed to become
clients of objects in other servers.
Encapsulation: the state of an object can be accessed only by the methods
of the object.

Note:
the state of an object refers to the data or attributes that represent the object at a
given moment

30
Remote method invocation (RMI): Design Issues

The distributed object model

The following two fundamental concepts are at the heart of the
distributed object model:
 Remote object references: is an identifier used to
uniquely locate and interact with a remote object.
 Remote interfaces: every remote object has a remote
interface that specifies which of its methods can be
invoked remotely. (For example, the objects B and F ,in
the figure shown on the next slide, must have remote
interfaces).

31
Remote method invocation (RMI): Design Issues

The distributed object model

32
Remote method invocation (RMI): Design Issues

Actions in a distributed object system

Action is initiated by a method invocation, which may result in further
invocations on methods in other objects. (in the figure shown on the previous
slide, object A might obtain a remote reference to object F from object B.)
When an action leads to the instantiation of a new object, that object will
normally live within the process where instantiation is requested. For
example, if the object L, shown in the figure, contains a method for creating
remote objects, then the remote invocations from C and K could lead to the
instantiation of the objects M and N, respectively.

33
Remote method invocation (RMI): implementation

34
Remote method invocation (RMI): implementation
 Object A invokes a method in a remote application-level object B for
which it holds a remote object reference.
 The two cooperating communication modules carry out the request-reply
protocol.
 A remote reference module is responsible for translating between local
and remote object references and for creating remote object references.
 Servants live within a server process. They are created when remote
objects are instantiated and remain in use until they are no longer
needed, finally being garbage collected or deleted.
 Proxy (Stub): The role of a proxy is to make remote method invocation
transparent to clients by behaving like a local object to the invoker; but
instead of executing an invocation, it forwards it in a message to a
remote object. It hides the details of the remote object reference, the
marshalling of arguments, unmarshalling of results and sending and
receiving of messages from the client.

35
Remote method invocation (RMI): implementation
 Together, the dispatcher and skeleton streamline the process of method
invocation over a network by routing requests and managing data
conversions, allowing remote objects to be accessed and manipulated
as if they were local objects.
 Dispatcher: is responsible for receiving incoming client requests and
directing them to the appropriate skeleton for further processing.
 Skeleton:
 acts as an intermediary between the dispatcher and the actual
remote object implementation.
 serves as a proxy on the server side
 It is responsible for
 unmarshaling the request data
 invoking the specified method on the remote object,
 marshaling the to be sent back to the client.

36
Remote method invocation (RMI): implementation
 The classes for the proxy, dispatcher and skeleton used in
RMI are generated automatically by an interface compiler.
 an interface compiler is a tool that automatically generates
the necessary classes and code to enable communication
between remote objects. Specifically, it creates proxy
(stub), dispatcher, and skeleton classes based on the
remote interface.

37