Chapter 4: Distributed Objects & Remote Invocation

44
Chapter 4: Distributed Objects & Remote Invocation

description

Chapter 4: Distributed Objects & Remote Invocation. Distributed Objects & Remote Invocation Introduction Communication between distributed objects Remote procedure call Events & notification. Objectives. - PowerPoint PPT Presentation

Transcript of Chapter 4: Distributed Objects & Remote Invocation

Page 1: Chapter 4: Distributed Objects & Remote Invocation

Chapter 4: Distributed Objects &

Remote Invocation

Page 2: Chapter 4: Distributed Objects & Remote Invocation

Distributed Objects & Remote Invocation

Introduction Communication between distributed objects Remote procedure call Events & notification

Page 3: Chapter 4: Distributed Objects & Remote Invocation

Objectives To study communication between distributed objects and the integration of remote method invocation into a programming language.

To explore the extension of the event-based programming model in order to apply to distributed event-based programs.

Page 4: Chapter 4: Distributed Objects & Remote Invocation

Introduced communication between distributed objects by means of remote method invocation (RMI) Objects that can receive remote method invocation are called remote objects

~ implement a remote interface

RMI have different semantic from local call because of possibility of independent failure of invoker & invoked objects Remote procedure call ~ RMI as procedure call to object invocation

Introduction

Page 5: Chapter 4: Distributed Objects & Remote Invocation

Concern with programming model in DS:

Remote procedure call model: ~allow client program to call procedure in server program running in separate process and generally in different computer from client.Object based programming model: ~ allow objects in different processes to communicate with one another by means of RMI.

Introduction (cont).

Page 6: Chapter 4: Distributed Objects & Remote Invocation

Remote method invocation (RMI)- extension of local method invocation - allows an object living in one process to invoke the methods of an object living in another process

Introduction (cont).

Page 7: Chapter 4: Distributed Objects & Remote Invocation

Distributed event-based programming model:

~ allow objects to subscribe to event occurring at remote objects of interest & in turn to receive notifications when such event occur.~ events and notification provide a way for heterogeneous objects to communicate with one another asynchronously.

Introduction (cont).

Page 8: Chapter 4: Distributed Objects & Remote Invocation

Figure 5.1Middleware layers

Applications

Middlewarelayers Request reply protocol

External data representation

Operating System

RMI, RPC and events

Software that provides a programming model above the basic building blocks of processes and

message passing is called middleware.

Page 9: Chapter 4: Distributed Objects & Remote Invocation

Middleware Programming ModelsDistributed objects & remote object

invocation is model explained as illustrated by Java RMICORBA:~ it provides remote object invocation

between a client program written in one language and a server program written in another language

~ another language commonly used is C++Other programming models~ remote event notification~ remote SQL access~ distributed transaction processing

Page 10: Chapter 4: Distributed Objects & Remote Invocation

InterfaceTo control the possible interactions between module-explicit interface is designed for each module.Specifies the procedures and variables that can be access from other module.2 types of interface in DS :

Service interfaces~ Used in client-server model~ Refer to the specification of procedures offered by

server and define input and output arguments. ~ Each server provides a set of procedures for client use

Page 11: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.2: CORBA IDL Examplestruct Person {

string name; string place;long year;

} ;interface PersonList {

readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out

Person p);long number();

};

Remote interface: ~ specifies the methods of an object available for remote invocation~ Can pass object as arguments and result of methods~ an interface definition language (or IDL) is used to specify remote interfaces. Ex: the above in CORBA IDL.~Java RMI have a class for Person, but CORBA has a struct

parameters are in, out or inout

remote interface

remote interface defines methods for RMI

CORBA has a struct

Page 12: Chapter 4: Distributed Objects & Remote Invocation

Communication Between Distributed

Object Model

Page 13: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object

Object based model for DS extend oriented programming language to make it apply the to distributed objects.We address communication between distributed objects by mean RMI. The material is presented under:~ the object model~ distributed objects~ the distributed object model~ design issue~implementation~ distributed garbage collection

Page 14: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)

Object ModelCommunicate with other by invoking their methodsCan encapsulate(summarize) their data and codeConsists of collection of interacting object :

- Object references - object can be accessed via object ref. - first class values, assigned to variables, pass as

arguments, and return as result.- Interfaces - definition of the signatures of a set of methods without

specifying their implementation. - object provide interface if its class contains code that implement the method of that interface.

Page 15: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)

- Action - is initiated by an object invoking a method in a another object. - Invocation included additional info needed to carry out

the method.- Exception - provide the clean way to deal with error without

complicating the code. - throw and catches – define a block of code- Garbage collection - freeing the space occupied by object when they are no longer needed.

Page 16: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.) Distributed object:

~ the state of an object consist of the value of its intense value.

~ adopt the client server architecture~ objects are managed by server~ clients invoke method by using RMI~ in RMI, client’s request to invoke a method of an object is

sent in a message to the server managing the object.~ execute method of object at server – result is return to

client in a another message ~ object in server are allowed to become client of object

in other server.

Page 17: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)The distributed object model:

~each process contains a collection of object.~can receive both ; local & remote invocation.RMI = method invocation between object in different process, whether in comp or not LMI = method invocation between object in same process

Page 18: Chapter 4: Distributed Objects & Remote Invocation

invocation invocation

remote

invocationremote

local

local

local

invocation

invocation

AB

C

D

E

F

each process contains objects, some of which can receive remote invocations, others only local invocationsthose that can receive remote invocations are called remote objects.- Object B and F are remote object.- Object C must have reference to object E to invoke their methods.objects need to know the remote object reference of an object in another process in order to invoke its methods.- A remote object for B must be available to A.remote interface specifies which methods can be invoked remotely.- Object B and F must have remote interface.

Fig. 5.3: Remote & local method invocations

Page 19: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)

Remote Interface - specifies the methods of an object that are available for invocation

by remote objects in other processes. - Interface definition languages (or IDLs) are designed to allow

objects in different languages to invoke one another. - Object in other process can remote only the method belong to it

remote interface.- The semantics of parameter passing are adjusted to suit the

separation of client and remote object.- Input and output parameters are used, and pointers cannot be

passed.

Page 20: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)Remote Object

- Object that can receive remote invocations.- one that can be invoked from another process.

Remote Object Reference- an identifier for a remote object - used to refer to a particular remote invocation.- Diff from local object references.- can be passed as an argument or result of a remote invocation. - clients need it in order to invoke remote objects.- may be obtained from a binder or as the result of an RMI.

Page 21: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.4: A remote object & its remote interface

interfaceremote

m1m2m3

m4m5m6

Data

implementation

remote object

{ of methods

-Object in other processes can invoke only the methods that belong to it remote interface

Page 22: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)Actions in distributed object system:- Object involved in a chain of related invocations may be

located in different process or different computer- When invocation crossed boundary of a process or

computer, RMI is used and remote references of the object must available to invoker.

- Object A needs to hold a remote object reference to object B.(refer to Fig 5.3)

- Object A may obtain a remote reference to object F from object B.(refer to Fig 5.3)

Page 23: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.5: Instantiation of remote objects

C

NM

Kinvocationremote

invocationremote

L

instantiateinstantiate

Distributed application may provide remote object with method for instantiating objects which can be accessed by RMI.Example:

~ Object L contains a method for creating remote object~ Remote invocation from method C and K could lead to instantiation

of the object M and N respectively.

Page 24: Chapter 4: Distributed Objects & Remote Invocation

Communication between Distributed Object (Cont.)Garbage collection distributed object system:

- Allow garbage collection of remote object - Cooperating existing local garbage collector & added module.

Exception: - process contains remote object – crashed/to busy/result

message lost -must be able to raise exception.

Page 25: Chapter 4: Distributed Objects & Remote Invocation

Design issues for RMI

The choices of invocation semantic The level of transparency that is desirable for RMI

Page 26: Chapter 4: Distributed Objects & Remote Invocation

RMI Invocation Semantics

Apply request-reply protocol.DoOperation implemented in different way to provide different delivery guarantees are:

Retry request message – retransmit the request message until either a reply is received or the server is assumed to have failedDuplicate filtering – when retransmission, it filter out duplicate request at server.Retransmission of result – keep history of result message, to enable lost result to be retransmitted without executing the operation at server.

Page 27: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.6: Invocation SemanticsFault 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 reply At-most-once

At-least-once

Maybe

Local invocations are executed exactly onceThe Request-reply protocol can apply fault-tolerance measures

Page 28: Chapter 4: Distributed Objects & Remote Invocation

Invocation Semantics: Failure Model

Maybe, At-least-once and At-most-once can suffer from crash failures when the server containing the remote object fails.

Maybe - remote method my be executed once or not at all- arise when none of the fault tolerance measures is applied- if no reply, the client does not know if method was executed or not~ omission failures if the invocation or result message is lost

- no retries after timeout ~ 2 situation (invocation message lost, method not executed or method

executed, result message lost) give impact to crash failure.- use fro apps which occasional failed invocation acceptable

Page 29: Chapter 4: Distributed Objects & Remote Invocation

Invocation Semantic: Failure Model

At-least-once - the client gets a result (and the method was executed at least once) or an

exception (no result)- suffer from arbitrary failures. If the invocation message is retransmitted, the remote object may execute the method more than once, possibly causing wrong values to be stored or returned. - if idempotent operations are used, arbitrary failures will not occur- idempotent operations, one that can be performed repeatedly with the

same effect although it have perform exactly once.- use in Sun RPC

At-most-once - the client gets a result (and the method was executed exactly once) or an exception (instead of a result, in which case, the method was executed once or not at all)- achieved by using all fault tolerance measure ~ prevent arbitrary failure – ensure each RMI method execute only once.- applied in JAVA RMI and CORBA, but CORBA allows maybe – requested method that do return result.

Page 30: Chapter 4: Distributed Objects & Remote Invocation

Call semantics cannot be `exactly once'. The

semantics achieved (e.g. `at-most-once') depends on the

approach to dealing with failures of processes and

communication.

Page 31: Chapter 4: Distributed Objects & Remote Invocation

Transparencyoriginator aimed to make RPC same as LPCHide marshalling, message passing, task of locating and contacting a remote objectRMI more vulnerable to failure than local invocation .Why?RMI latency is greater than local- to minimize, caller able to abort RPC that taking a lot of time.To differentiate the syntax of RMI with LMI

Page 32: Chapter 4: Distributed Objects & Remote Invocation

Implementation of RMI

Roles of components that involve in implementation of RMI

Page 33: Chapter 4: Distributed Objects & Remote Invocation

Implementation of RMI(cont.)

Communication Module- Define the client and the server- Use only first 3 items – specify msg type, requestID and remote reference.- Responsible to provide a specified invocation semantics

Remote reference module- responsible to translate between local and remote object references- create remote object reference- each process have remote object table

Page 34: Chapter 4: Distributed Objects & Remote Invocation

Implementation of RMI(cont.)

Servant - an instance of class which provide the body of remote object- handles the remote request pass and live within a server process- deleted after being used.

The RMI software- consist a layer of software between apps level object-

communication- remote reference modules- Proxy

~ make RMI transparent to client- behave like local object and hide details- Dispatcher

~ receive request msg from comm. module ~ use methodID to select appropriate method in

skeleton

Page 35: Chapter 4: Distributed Objects & Remote Invocation

object A object BskeletonRequest

proxy for B

Reply

CommunicationRemote Remote referenceCommunication module modulereference module module

for B’s class& dispatcher

remoteclient server

RMI software - between application level objects &communication & remote reference modules

carries out Request-reply protocol

translates between local and remote object references and creates remote object references. Uses remote object table

Fig. 5.7: The role of proxy & skeleton in remote method invocation

Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests & unmarshals results.Forward requestDispatcher - gets request from communication module and invokes method in skeleton (using methodID in message).

Skeleton - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object.

Page 36: Chapter 4: Distributed Objects & Remote Invocation

Distributed Garbage Collection

To ensure a local or remote reference to an object remain exist if still in useAs soon no object any longer hold a reference to it, the object will be collected and memory uses is recovered.

Page 37: Chapter 4: Distributed Objects & Remote Invocation

Remote Procedure Call Very similar to remote method

invocation Generally implemented in request-reply

protocol Client program calls a procedure in

another program running in server process

Its service interface have lack of ability to create new instance of object – do not support remote object references

Implemented over request –reply protocol- same content but object reference field is omitted(lost).

Page 38: Chapter 4: Distributed Objects & Remote Invocation

Remote Procedure CallClient Stub procedure- Similar to proxy method- Behave like local procedure to client- Marshall procedure identifier and the argument in request msg

Server stub procedure- similar to skeleton method- unmarshals argument in the request msg, call coresponding service procedure and marshal return value for reply msg

Page 39: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.8: Role of client & server stub procedures in RPC in the context of a procedural language

client

Request

Reply

CommunicationCommunication

module module dispatcher

service

client stub

server stubprocedure procedure

client process server process

procedureprogram

Page 40: Chapter 4: Distributed Objects & Remote Invocation

Distributed event-based systems

- use the publish-subscribe paradigm - event-generating object publishes type of events that will be available for other objects.

- Object that receive notification of publishes event subscribe the types of their interest event. - 2 main characteristics: i) heterogeneous; ii) asynchronous- useful for communication between heterogeneous components - their asynchronous nature allows publishers and subscribers to

be decoupled.

Events And Notification

Generally implemented in request-reply protocol

Page 41: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.10: Dealing Room SystemDealer’s computer

Informationprovider

Dealer

Externalsource

Externalsource

Informationprovider

Dealer

Dealer

Dealer

Notification

Notification

Notification

Notification

NotificationNotification

Notification

Notification

Dealer’s computer

Dealer’s computerDealer’s computer

NotificationNotification

The figure shows an example of distributed event-based systems.

Page 42: Chapter 4: Distributed Objects & Remote Invocation

- Allows user to see the latest info about the market price- Market price are represent by an object with instance variables.- Info have been updated and collected by information provider.

- 2 different task create here : i. - information provider update to the appropriate stock object - update to stock object regards as an event - notify all the dealer who have subscribe - for each external source there will be separate info provider process

ii. - dealer create object to represent named stock - local object subscribe to the relevant info provider object - receive info sent to it in notification and display to user

Dealing Room System

Page 43: Chapter 4: Distributed Objects & Remote Invocation

Fig. 5.11: Architecture for distributed event notification

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification

Page 44: Chapter 4: Distributed Objects & Remote Invocation

• The object of interest – an object that experience change of state• Event – occur at an object of interest as the result of completion of

method execution• Notification – an object that contain info about an event• Subscriber - an object that subscribe to some type of event in

another object.• Observer object – to decouple an object of interest of its

subscriber.• Publisher – declare it will generate notification of particular types

of an event. can be object of interest or an observer.

1. An object of interest inside the event service without an observer. It send notifications directly to the subscribers.

2. inside the event service with an observer. The object interest send notification via observer.

3. outside the an event service. observer queries the object of interest to discover when event occur and observer sends notification

Distributed event notification