The document discusses programming models for distributed systems, focusing on remote invocation and the various protocols involved in client-server communication, such as Remote Method Invocation (RMI) and CORBA. It explains concepts like local vs. remote method invocations, remote object references, and the structure of the RMI architecture, detailing how clients and servers communicate through stubs and skeletons to facilitate method calls. Additionally, it addresses error handling, invocation semantics, and the design choices that affect reliability and fault tolerance in remote invocations.

1. (2024-2025) – 2nd semester
Ch5
Remote invocation
Distributed Systems

2. Programming Models for
Distributed Communications
Request-reply protocols: message passing in client-server computing.
Remote Procedure Calls: The client calls a procedure implemented and
executed on a remote computer. Call as if it was a local procedure.
Remote Method Invocation: Local object invokes methods of an object
residing on a remote computer. Invocation as if it was a local method
call
Event-based Programming Model: Objects receive notice of events in
other objects in which they have an interest.

3. Object Model
➢ An object-oriented program (Java, C++, ...) consists of a collection of
interacting objects, each of which consists of a set of data and a set of
methods.
➢ An object can communicate with other objects by invoking their
methods, generally passing arguments and receiving results
(request/reply protocol).
➢ Objects can encapsulate their data and the code of their methods.
➢ In a distributed object system, an object’s data should be accessible
only via its methods (or interface).
➢ The receiving object executes the appropriate method and then returns
control to the invoking object, sometimes supplying a result.

4. Object Model (continued)
➢An invocation of a method can have 3
possible effects:
✓the state of the receiver may be
changed
✓a new object may be instantiated
✓further invocations on methods in
other objects may take place

5. Local Method Invocations
Method invocations between objects
in the same process are local method
invocations
Process Object Process
Process
invocation invocation
remote
invocation
remote
local
local
local
invocation
invocation
A
B
C
D
E
F
Host A
Host B

6. Remote Method Invocations
Method invocations between objects in
different processes, whether in the same
computer or not, are known as remote
method invocations
Process Object Process
Process
invocation invocation
remote
invocation
remote
local
local
local
invocation
invocation
A
B
C
D
E
F
Host A
Host B

7. The Distributed Objects
object state data item
object operation
Host A Host B
client process
method call
a distributed object

8. Distributed Object Systems/Protocols
The distributed object paradigm has been widely adopted in
distributed applications, for which a large number of
mechanisms based on the paradigm are available. Among
the most well known of such mechanisms are:
✓ Java Remote Method Invocation (RMI),
✓ The Common Object Request Broker Architecture (CORBA) systems,
✓ .NET and its predecessor, the Distributed Component Object Model
(DCOM)
✓ Mechanisms that support the Simple Object Access Protocol (SOAP).
The most straightforward is the Java RMI

9. Remote Method Invocation
Server Side
send client data
(request)
receive server data/result
(reply)
Remote Object
runs procedure
Client Side

10. Remote Method Invocation
Fundamental concepts of the distributed object model:
Remote object reference:
◦ An identifier that can be used globally throughout a
distributed system to refer to a particular unique
remote object.
Remote interface:
◦ Every remote object has a remote interface that
specifies which of its methods can be invoked
remotely.

11. Remote Interface
The remote interface
specifies which methods of
an object can be invoked
remotely
Data
m4
m5
m6
Remote
interface
m1
m2
m3
{
The class of a remote object
implements the methods of
its remote interface.
Local objects can invoke the
methods in the remote interface as
well as other methods implemented
by a remote object
Data
implementation
remote object
of methods

12. RMI Architecture
Server
Skeleton
Client
Stub
Remote Reference Layer
Transport Layer
Presentation
Session
Transport
The layers are independent. Each layer is defined by specific protocol and built
using specific interface.
Any layer can be replaced by an alternate implementation without affecting the
others, e.g. the current transport layer in RMI is TCP based, but can be
substituted by a UDP based transport layer
OSI Model
Application

13. RMI Architecture
Stub/Skeleton Layer:
◦ The Interface of the application with the rest of the system.
◦ This layer transmits the data to the remote reference layer.
Remote Reference Layer:
responsible for providing the ability to support varying remote
reference or invocation protocols independent of client stubs and
server skeletons.
A stub is an agent for the remote object, It resides on the client-
side and handles all the interaction with the remote object.
A skeleton handles the communication on the server side.

14. Transport Layer: Responsible for managing connection:
◦ Setting up connections
◦ Listening to incoming calls
◦ Maintaining table of remote objects that reside in same
address space
RMI Architecture
Remote object references are represented by an object
identifier and end point. This representation is called a
live reference. Given a live reference for a remote object
the identifier looks up the targeted remote object and the
end point sets up the connection to the address space the
object resides.

15. • The remote object must register itself with the RMI naming registry.
• The server calls the registry to associate the name with a remote object.
• The client looks up a remote object by name in the server's registry.
• The client invokes the method on an object.
RMI
RMI
RMI
URL
protocol
URL
protocol
Client
Web Server
Registry
Web Server
Server
References to Remote Object

16. How does RMI work?
Client Stub Skeleton Server
local call to
stub method local call to
server method
Sending
marshalled
parameters
return value or
throw exception
Sending marshalled
return value or
exception

17. How does RMI work?
skeleton
marshal parameters;
send Request
unmarshal parameters
Invoke method
Remote
Method
execute code
and return a
value
receive return value
marshal reply
send reply
unmarshall reply;
return value
time
(based on http://java.sun.com.marketing/collateral/javarim.html)
stub

18. How does RMI work?
When a stub's method is invoked, it does the following:
• Initiates connection with the remote object
• Marshals the parameters
• Waits for result of method invocation
• Unmarshals the value or exception returned
• Returns value to caller
On the server side, the skeleton or receiver object
• Unmarshals the parameters of the remote method
• Locates object to be called
• Calls desired method on remote object implementation
• Captures and marshals return value or exception to the caller.

19. Parameter Marshalling and Unmarshalling
When a client code invokes a remote method on a remote object, it actually calls
an ordinary/local method encapsulated in the stub.
The stub encodes the parameters used in the remote method with a device-
independent encoding and transforms them in a format suitable for transport.
The process of encoding, writing to a stream and sending an object is referred as
parameter marshalling.
How does RMI work
Thus the stub method on the client side builds an information block that consists
of:
• Identifier of remote object to be used;
• Name of the method to be called
• Marschalled parameters.
The reverse process of receiving, reading and decoding is called parameter
unmarshalling.

20. Distributed Garbage Collection
In stand-alone application objects that are no longer
referenced by any client are automatically deleted.
RMI provides distributed garbage collector that
automatically removes objects that are no longer
referenced by any client.
RMI uses a reference counting garbage collection that keeps
track of all live references of a given object.
When a live reference enters its count is incremented, when
it becomes unreferenced, its count is decremented; when
the count is 0 (no live reference) the object can be garbage
collected.

21. Exceptions
◦Any remote invocation may fail for
reasons related to the invoked object being
in a different process or computer from
the invoker.
◦For example, the process containing the
remote object may have crashed or maybe
too busy to reply, or the invocation or
result message may be lost.
◦Remote method invocation should be able
to raise exceptions.

22. Failure Modes
Execute
Reply
Correct function
Execute,
Crash
Request
Crash
Request
Request
Execute
crash
before
reply
crash
before
execution
lost
request
Reply
Channel
fails
during
reply
Reply
Client
machine
fails
before
receiving
reply
Request
Execute
Request
Request
(and if request is received more than once?)
Exceptions

23. Local Method Invocation Semantics
Local method invocations are executed exactly once
invocation semantics
Exceptions
= every method is executed exactly once.
◦ So RMI, can be implemented in different ways to
provide different delivery guarantees.
◦ These choices lead to a variety of possible semantics
for the reliability of remote invocations as seen by the
invoker.
This cannot always be the case
for remote method invocation!

24. Main Design Choices for Implementing RMI
Retry request message: whether to retransmit the request message until
Sender Receiver
…………
.
………………………….
request
Error control mechanisms:
timeout + retransmission of request msg
deadlock!
either a reply is received or the server is assumed to have failed.
Exceptions

25. Main Design Choices for Implementing RMI
Duplicate filtering: when retransmissions are used,
Sender Receiver
…………………........
………………………….
request
Error control mechanisms:
numbering scheme
whether to filter out duplicate requests at the server
request
reply
timeout
Exceptions

26. Main Design Choices for Implementing RMI
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.
Sender Receiver
……………………......
………………………….
request
Error control mechanisms:
numbering scheme + history of result
request
reply
timeout
operation
operation
Exceptions

27. Invocation Semantics
Combination of these choices lead to a variety of possible semantics for the reliability
of remote invocations: Maybe, At-least-once, At-most-once.
Invocation Semantics: Maybe
◦ The remote method may be executed once or not at all.
◦ Maybe semantics arises when no fault tolerance measures are applied.
Invocation Semantics: At-Least-Once
◦ a result, in which case the invoker knows that the method was executed at least
once, or an exception informing it that no result was received.
Invocation Semantics: At-Most-Once
◦ a result, in which case the invoker knows that the method was executed exactly
once, or
◦ an exception informing it that no result was received, in which case the method
will have been executed either once or not at all.
Exceptions

28. Invocation Semantics
Fault tolerance measures Invocation
semantics
Retransmit request
message
Duplicate
filtering
Re-execute procedure
or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit old reply At-most-once
At-least-once
Maybe
Whether or not to
retransmit the request
message until either
a reply is received or
the server is assumed
to be failed
when retransmissions
are used, whether to
filter out duplicate
requests at the server.
whether to keep a
history of result
messages to enable
lost results to be
retransmitted without
re-executing the
operations
(ok for idempotent operations)
Idempotent=same result if applied repeatedly, w/o side effects
Exceptions