Chapter 5 Distributed systems

D.ABHISHEKH MSSE SV COLLEGES

1 CHAPTER-5(UNIT-2) DISTRIBUTED OBJECTS & REMOTE INVOCATION

CHAPTER-5 Distributed Objects & Remote Invocation

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):

Allows Client programs to call procedures in server

programs running in separate processes and generally in

different computer from client

Remote Method Invocation (RMI):

An extension of local method invocation that allows an

object living in one process to invoke the methods of an

object living in another process

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.

MIDDLEWARE

Software that provides a programming model above the basic

building blocks of processes and message passing is called

middleware

It uses protocols based on messages between processes to provide

its higher level abstractions such as remote invocations and events

Example remote invocation abstraction is based on the request

reply protocol

The important aspects of middleware are



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.

INTERFACES IN DISTRIBUTED SYSTEMS

In a distributed program, the modules can run separate process. It is not

possible for a module running in one process to access the variables in a

module in another process. Therefore the interface of a module that is

intended for RPC or RMI cannot specify direct access, however the

attributes are not accessed directly but by means of some getter and

setter procedures added automatically to the interface

DISTRIBUTED OBJECTS

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 OBJECT 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.



Object B and F are remote objects and they must have remote

interface

the remote object to receive a remote method invocation is

specified by the invoker as a remote object reference

DESIGN ISSUES FOR RMI

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:

Retry request message until a reply is received or the server

is assumed to be failed

Duplicate filtering when a retransmission are used whether to

filter out duplicate request at the server.

Retransmission of results 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.



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.

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).

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.

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.

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).

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.



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.



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.



EVENTS & NOTIFICATIONS

The idea behind the use of events is that one object can react to a

change occurring in another object. Notifications of events are

essentially asynchronous & determined by their receivers

Distributed events- based systems extend the local event model by

allowing multiple objects at different locations to be notified of

events taking place at an object they use PUBLISH-SUBSCRIBE

PARADIGM , in which an object that generates events publishes the

type of events that it will make available for observation by other

objects. Objects that want to receive notifications from an object

that has published its events subscribe to the types of events that

are of interest to them. objects that represent events is called

notifications

Dealing with room system

Dealers

Information provider

Dealer

Externasourc

External source

Information provider

Dealer

Dealer Dealer

Notification

Notification

Notification

Notification

Notification Notification

Notification

Notification

Dealers

Dealers Dealers Notification

Notification



There are three layers that comprise the basic remote-

object communication facilities in RMI:

1. The stub/skeleton layer, which provides the

interface that client and server application objects

use to interact with each other.

CClliieenntt SSeerrvveerr

SSttuubbss SSkkeelleettoonnss

RReemmoottee

RReeffeerreennccee RReemmoottee

RReeffeerreennccee

TTrraannssppoorrtt



2. The remote reference layer, which is the

middleware between the stub/skeleton layer and the

underlying transport protocol.

3. The transport protocol layer, which is the binary

data protocol that sends remote object requests

over the wire.

Description of the architecture:

1. The client uses the client-side stub to make a request of the

remote object. The server object receives this request from a

server-side object skeleton.

2. A client initiates an RMI invocation by calling a method on a stub

object. The stub maintains an internal reference to the remote

object it represents and forwards the method invocation request

through the remote reference layer by marshaling the method

arguments into serialized form and asking the remote reference

layer to forward the method request and arguments to the

appropriate remote object.

3. Marshaling involves converting local objects into portable form

so that they can be transmitted to a remote process. Each

object (e.g. a String object, an array object, or a user defined

object) is checked as it is marshaled, to determine whether it

implements the java.rmi.Remote interface. If it does, its remote

reference is used as its marshaled data. If it isnt a Remote

object but is rather a Serializable object, the object is

serialized into bytes that are sent to the remote host and

reconstructed into a copy of the local object. If the object is



neither Remote nor Serializable, the stub throws a

java.rmi.MarshalException back to the client.

4. If the marshaling of method arguments succeeds, the client-side

remote reference layer receives the remote reference and

marshaled arguments from the stub.

5. The remote reference layer converts the client request into low-

level RMI transport requests, i.e., into a single network-level

request and sends it over the wire to the sole remote object

that corresponds to the remote reference passed along with the

request.

6. On the server, the server-side remote reference layer receives

the transport-level request and converts it into a request for

the server skeleton that matches the referenced object.

7. The skeleton converts the remote request into the appropriate

method call on the actual server object. This involves

unmarshaling the method arguments into the server environment

and passing them to the server object. Arguments sent as

remote references are converted into local stubs on the server,

and arguments sent as serialized objects are converted into local

copies of the originals.

8. If the method calls generates a return value or an exception, the

skeleton marshals the object for transport back to the client

and forwards it through the server reference layer.

The result is sent back using the appropriate transport protocol (e.g.

Socket API using TCP/IP), where it passes through the client reference

layer and stub, is unmarshaled by the stub, and is finally handed back to

the client thread that invoked the remote method.



RMI REGISTRY

Naming/Registry Service

A server process needs to register one (or more) RMI-

enabled objects with its local RMI registry (represented by

the Registry interface) using a name that clients can use to

reference it.

A client can obtain a stub reference to the remote object by

asking for the object by name through the Naming interface.

The Naming.lookup() method takes the name of a remote

object and locates the object on the network. The objects

name is in a URL-like syntax that includes the name of the

objects host and the objects registered name.

Once the lookup() method locates the objects host, it

consults the RMI registry on the host and asks for the object

by name. If the registry finds the object, it generates a

remote reference to the object and delivers it to the client

process, where it is converted into a stub (local) reference

that is returned to the caller.

FORMAT: rmi//ComputerName/ObjectService

Chapter 5 Distributed systems

Documents

interface distributed

clients of objects

collection of objects

distributed object model

distributed systems

distributed object systems

distributed programming

distributed applications