Cloud Computing

Lecture 05

Chapter 2 – Principles of Parallel and Distributed

Computing

1
Models for interprocess communication
 Distributed systems are composed of a collection of concurrent
processes interacting with each other by means of a network
connection.
 IPC is used to exchange data and coordinate the activity of processes.
 IPC ties together the different components of a distributed system
making them act as a single system.
 Different models in which processes can interact with each other:
• shared memory
• remote procedure call (RPC)
• message passing

2
Message-based communication
 Distributed system:
“one in which components located at networked computers communicate
and coordinate their actions only by passing messages.”
 Message
• Discrete amount (limited in size and time) of information that is passed
from one entity to another.
 Distributed programming paradigms using messaged-based
communication:
• Message Passing
• Remote Procedure Call
• Distributed Objects
3
Message-based communication
• Message Passing
– The entities in the distributed environment exchange information encoded in the
form of a message.
• Remote Procedure Call
– Extends the concept of procedure call to execute code in a remotely located
process.
– A remote process hosts a server component allowing client processes to request
the invocation of methods, and returns the result of the execution.
• Distributed Objects
– An implementation of the RPC model for the object-oriented paradigm for
remote invocation of methods exposed by objects.
– Each process registers a set of interfaces that are accessible remotely.
– Client processes can request a pointer to these interfaces and invoke the methods
available through them. 4
Models for message-based communication
 Another important aspect in message-based communication is:
• The way messages are exchanged among components.
• Messages are exchanged among how many components?
 Message Models:
• Point-to-point
• Publish-and-subscribe
• Request-reply
 A combination of models is used in order to design and implement all
communication needs within a distributed system.

5
Models for message-based communication
 Point-to-point message model
• Communication among single components (one component to another
with direct addressing).
• It is necessary to know the location other component in the system.
• There is no central infrastructure that dispatches the messages.
• Communication is initiated by the message sender.
• Two major subcategories:
– Direct communication: the message is sent directly to the receiver and
processed at the time of reception
– Queue-based communication: the receiver maintains a message queue in which
the messages received are placed for later processing.

6
Models for message-based communication
 Publish-and-subscribe message model
• Communication based on notification among components.
• There are two major roles:
1. Publisher:
– Provides facilities for subscriber to register its interest in a specific event.
– Specific conditions holding true creates the message(s) attached to a specific event.
– Message(s) is available to all the subscribers that registered for the corresponding event.
2. Subscriber
– Registers for an event to receive associated message(s).
• There are two major strategies for dispatching message(s) to the subscribers:
1. Push strategy
– Publisher notifies all the subscribers.
2. Pull strategy
– Publisher only creates the message and subscriber(s) is responsible to check if there are any messages
available on the event for which they registered. 7
Models for message-based communication
 Request-reply message model
• Communication model in which for each message sent by a process,
there is a reply.
• Point-to-point message models are more likely to be based on a request-
reply interaction.
• Publish-and-subscribe models are less likely to be based on request-
reply since they rely on notifications.

8
Technologies for distributed computing
 Relevant technologies providing interaction models using message-
based communication:
• Remote procedure call
• Distributed object frameworks
• Service-oriented computing

9
Remote procedure call
 RPC is the fundamental abstraction enabling the execution of
procedures on client’s request.
 RPC allows extending the concept of a procedure call beyond the
boundaries of a process and a single memory address space.
 The called procedure and calling procedure may be on the same system
or they may be on different systems in a network.
 RPC has been a dominant technology for IPC.
 Several programming languages and environments support RPC in the
form of libraries and additional packages.
• RPyC is an RPC implementation for Python
• XML-RPC and JSON-RPC provides RPC facilities over XML and JSON.
10
Remote procedure call
 Marshaling
• The process of converting parameter and return values into a form that is
more suitable to be transported over a network through a sequence of
bytes.
 Marshaling and unmarshaling are performed by the RPC runtime
infrastructure.
 RPC runtime is responsible for parameter packing, unpacking, and for
handling the request-reply interaction that happens between the client
and the server process in a completely transparent manner.

11
Remote procedure call
 Developing a system leveraging RPC for IPC consists of the following
steps:
• Design and implementation of the server procedures that will be exposed
for remote invocation.
• Registration of remote procedures with the RPC server on the node
where they will be made available.
• Design and implementation of the client code that invokes the remote
procedure(s).

12
FIGURE 2.14 The RPC reference model

13
Distributed object frameworks
 Extension of object-oriented programming systems
 Allows objects to be distributed across a heterogenous network
 Makes objects appear as they are in same address space
 Common Interaction pattern:
1. The server process maintains a registry of active objects that are made
available to other processes.
2. The client process, by using a given addressing scheme, obtains a
reference to the active remote object.
3. The client process invokes the methods on the active object by calling
them through the reference previously obtained.

14
Distributed object frameworks
 A mechanism called a proxy skeleton creates the illusion of
interaction with a local instance.
 Proxy and skeleton always constitute a pair.
• Server process maintains the skeleton component, which is responsible
for executing the methods that are remotely invoked.
• Client maintains the proxy component, allowing its hosting environment
to remotely invoke methods through the proxy interface.

15
FIGURE 2.15 The distributed object programming model

16
Distributed object frameworks
 Object activation and lifetime
• Server-based activation
– The active object is created in the server process and registered as an instance
that can be exposed beyond process boundaries.
– The lifetime of an object is generally user-controlled.
• Client-based activation
– The active object does not originally exist on the server side; it is created when a
request for method invocation comes from a client.
– The lifetime is controlled by some policy of the runtime infrastructure.

17
Distributed object frameworks
 Popular technologies for enabling distributed object programming:
• Common object request broker architecture (CORBA)
– CORBA is a specification for providing cross-platform and cross-language
interoperability among distributed components.
– Not very popular due to complex development phase.
• Distributed component object model (DCOM/COM+)
– Solution provided by Microsoft for distributed object programming before the
introduction of .NET technology.
• Java remote method invocation (RMI)
– Allows the invocation of methods on objects that are located on different Java Virtual
Machines (JVMs) residing on remote or local node.
• .NET remoting
– Allows IPC among .NET applications by providing a uniform platform for accessing
remote objects from within any application developed in any of the languages
18
supported by .NET.