distributed obj and remote invocation

7/30/2019 Distributed Obj and Remote Invocation

1/46

Introduction Communication between distributed

objects

Remote procedure call Events and notifications

Java RMI case study Summary

Chapter 5: Distributed objects and remote invocation


2/46

Layers ofMiddleware Provide a programming model

Provide transparence

Location

Communication protocols

Computer hardware

Operating systems

Programming languages

Middleware


3/46

Figure 5.1 Middleware Layers

Applications

MiddlewarelayersRequest reply protocol

External data representation

Operating System

RMI, RPC and events


4/46

Remote procedure call (RPC)call procedure in separate process

Remote method invocation (RMI)

extension of local method invocation in OO modelinvoke the methods of an object of another process

Event-based model

Register interested events of other objectsReceive notification of the events at other objects

Distributed programming model


5/46

InterfaceSpecifies accessible procedures and variables Inner alteration wont affect the user of the

interface

Interface in distributed system Cant access variables directly

Inputargument and outputargument

Pointers cant be passed as arguments or returned

results

Interfaces


6/46

RPCs Service interface specification of the procedures of the server, defining the

types of the input and output arguments of each procedure

RMIs Remote interface Specification of the methods of an object that are available for

objects in other processes, defining the types of them.

may pass objects or remote object references as arguments orreturned result

Interface definition languages program language, e.g. Java RMI Interface definition languages (IDLs), are designed to allow

objects implemented in different languages to invoke oneanother.

e.g. CORBA IDL (n1), DCE IDL and DCOM IDL

Interface cases


7/46

CORBA IDL example

Remote interface:

specifies the methods of an object available for remote invocation

an interface definition language (or IDL) is used to specify remote interfaces.

E.g. the above in CORBA IDL.

Java RMI would have a class for Person, but CORBA has a struct

struct Person {

string name;

string place;

long year;

} ;

interface PersonList {

readonly attribute string listname;

voidaddPerson(in Person p) ;

voidgetPerson(in string name, out Person p);

longnumber();

};parameters are in, outor inout

remote interface

remote interface defines

methods for RMI

CORBA has a struct


8/46


objects


Java RMI case study Summary



9/46

Distributed object model

invocation invocation

remote

invocationremote

local

local

local

invocation

invocation

AB

C

D

E

F

each process contains objects, some of which can receive remoteinvocations, others only local invocations

those that can receive remote invocations are called remote objects objects need to know the remote object reference of an object in

another process in order to invoke its methods.

the remote interface specifies which methods can be invoked remotely

Figure 5.3


10/46

RMI Fault Tolerance

A remote object system will also need a way to

detect and handle faults. Errors can occur in the

calling system, the called system, or on thenetwork, so this is more complex than local fault

handling.

Different semantics are used for reliability,

involving retransmission or notification andattempting to avoid duplication.


11/46

Fault Tolerance Measures

Retry Request Message Determines if the requesting system should retransmit a request

until a response is received

Duplicate Filtering Determines if the same request received multiple times should be

filtered down to one request, or if all requests should be re-executed

Retransmission of Results

Determines if the results from requests should be saved and resentinstead of re-executing a request


12/46

Invocation Semantics

Maybe Invocation Semantics

Remote method requests may be executed once

or not at allUsed when request messages are not resent

when a fault occurs

Requesting system cannot tell if the serverexecuted the request before the fault occurred


13/46

Invocation Semantics Cont.

At-Least-Once Invocation Semantics Requesting system receives either a result or an exception

Server will re-execute a request for each retry request message received

Not appropriate when executing the same method multiple times will alterthe result Example: A request to withdraw $10 from a bank account cannot be processed within the

timeout limit because the server is busy. The client resends the request messages 5 timesbefore the server starts processing new requests. The server will executes the withdrawrequest 5 times. The result is that instead of $10 being withdrawn, $50 is taken out of theaccount. This is not an acceptable result!


14/46


15/46

Invocation semantics

Local invocations are executed exactly once

Remote invocations cannot achieve this. Why not?

the Request-reply protocol can apply fault-tolerancemeasures

Fault tolerance measures Invocationsemantics

Retransmit requestmessage

Duplicatefiltering

Re-execute procedureor retransmit reply

No

Yes

Yes

Not applicable

No

Yes

Not applicable

Re-execute procedure

Retransmit reply At-most-once

At-least-once

Maybe


16/46


17/46

Communication & Remote

Reference Modules

Communication Module

Transmits request and reply messages

Concerned with the Message Type, requestId, and the remote reference ofthe object

Specifies the Invocation Semantics (Ex: At-Most-Once)

Selects the dispatcher for the objects class to be invoked

Remote Reference Module

Translates the remote object reference in a message to a local objectmessage and vice versa

Creates new remote object references Maintains the local to remote object references in a Remote Object Table


18/46

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

modulemodulereference modulemodule

for Bs class

& dispatcher

remoteclient server

translates between local and remote

object references and creates remote

object references. Uses remote object

table

The architecture of remote method invocation

RMI software - between

application level objects

and communication and

remote reference

modulesDispatcher- gets request from communication module and

invokes method in skeleton (using methodIDin message).

carries out Request-

reply protocol

Proxy- makes RMI transparent to client. Classimplements remote interface. Marshals requests and

unmarshals results. Forwards request.

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

method in remote object.


19/46


objects


Java RMI case study

Summary



20/46

RPC is very similar to RMI

Service interface: the procedures that are available for remote calling

Invocation semantics choice: at-least-once or at-most-once Generally implemented over request-reply protocol

Building blocks Communication module

Client stub procedure (as proxy in RMI): marshalling, sending, unmarshalling

Dispatcher: select one of the server stub procedures Server stub procedure (as skeleton in RMI): unmarshalling, calling, marshalling

client

Request

Reply

CommunicationCommunicationmodulemodule dispatcher

service

client stub server stubprocedure procedure

client process server process

procedureprogram


21/46

Sun RPC case study

Bindingportmapper Server: register ((program number, version number), port

number)

Client: request port number by (program number, version

number)

Authentication Each request contains the credentials of the user, e.g. uid and

gid of the user

Access control according to the credential information


22/46


objects


Java RMI case study

Summary



23/46

Event-notification model

Idea

one object react to a change occurring in another object

Event examples modification of a document

an electronically tagged book being at a new location

Publish/subscribe paradigm event generator publish the type of events

event receiver subscribe to the types of events that are interest to them

When event occur, notify the receiver

Distributed event-based systemtwo characteristics Heterogeneous: components in a DS that were not designed to interoperate can b

made to work together

Asynchronous: prevent publishers needing to synchronize with subscribers


24/46

Example - dealing room system

Requirementsallow dealers to see the latest market price of the

tocks they deal in.

System components

Information provider receive new trading information

publish stocks prices event

stock price update notification

Dealer process subscribe stocks prices event

System architecture


25/46


26/46

Architecture for distributed event notification

Event service: maintain a database of published events and of

subscribers interests decouple the publishers from the subscribers

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification


27/46

The roles of the participating objects

The object of interest

its changes of state might be of interest to other objects

Event An event occurs at an object of interest as the completion of a method execution

Notification an object that contains information about an event

Subscriber an object that has subscribed to some type of events in another object

Observer objects the main purpose is to decouple an object of interest from its subscribers.

Avoid over-complicating the object of interest. Publisher

an object that declares that it will generate notifications of particular types of

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


28/46

Notification delivery

Delivery semantics Unreliable, e.g. deliver the latest state of a player in a

Internet game

Reliable, e.g. dealing room

real-time, e.g. a nuclear power station or a hospital patientmonitor

Roles for observers Forwarding

send notifications to subscribers on behalf of one or more objects ofinterests

Filtering of notifications according to some predicate Patterns of events

Notification mailboxes notification be delayed until subscriber being ready to receive


29/46

Jini distributed event specification

EventGeneratorinterface

Provide registermethod Event generator implement it

Subscriber invoke it to subscribe to the interested events

RemoteEventListenerinterface

Provide notifymethod subscriber implement it

receive notifications when the notify method is invoked

RemoteEvent

a notification that is passed as argument to the notify method Third-party agents

interpose between an object of interest and a subscriber

equivalent ofobserver


30/46

Introduction

Communication between distributed

objects


Java RMI case study

Summary



31/46

Java RMI introduction

Remote object Must implement the remote interface

must handle remote exceptions

Arguments and return results of remote method

Must be serializable All primitive types serializable

remote objects are serializable

File handles are unserializable

Remote objects are passed as remote object reference, non-

remote serializable objects are copied and passed by value

RMIregistry

access by theNaming class


32/46


33/46

Design and implementation of Java RMI

Java classes supporting RMI

RemoteServer

UnicastRemoteObject

Activatable

RemoteObject


34/46


35/46

Summary

Two paradigms for distributed programming

RMI(RPC)/Event notification: sync./async.

RMI

Distributed object model

Remote interface, remote exception, naming service

Remote invocation semantics

Once, at-least-once, at-most-once

Example: whiteboard based on Java RMI

Sun RPC Event-notification

Publish/subscribe

Event service

Example: dealing room


36/46


37/46


38/46

Remote and local method invocations

invocation invocation

remote

invocationremote

local

local

local

invocation

invocation

AB

C

D

E

F


39/46

Files interface in Sun XDR

const MAX = 1000;

typedef int FileIdentifier;typedef int FilePointer;

typedef int Length;

structData {

int length;

char buffer[MAX];

};

structwriteargs {

FileIdentifier f;

FilePointer position;

Data data;

};

structreadargs {

FileIdentifier f;

FilePointer position;

Length length;

};

program FILEREADWRITE {

version VERSION {

voidWRITE(writeargs)=1; 1

DataREAD(readargs)=2; 2}=2;

} = 9999;

D li


40/46

Dealing room system

Dealers computer

Information

provider

Dealer

External

source

External

source

Information

provider

Dealer

Dealer

Dealer

Notification

Notification

Notification

Notification

NotificationNotification

Notification

Notification

Dealers computer

Dealers computerDealers computer

NotificationNotification


41/46

TheNaming class of Java RMIregistry

voidrebind(String name, Remote obj)

This method is used by a server to register the identifier of a remote object byname, as shown in Figure 15.13, line 3.

voidbind(String name, Remote obj)

This method can alternatively be used by a server to register a remote object

by name, but if the name is already bound to a remote object reference an

exception is thrown.voidunbind(String name, Remote obj)

This method removes a binding.

Remote lookup(String name)

This method is used by clients to look up a remote object by name, as shown

in Figure 15.15 line 1. A remote object reference is returned.

String [] list()

This method returns an array of Strings containing the names bound in the

registry.


42/46

Java Remote interfaces Shape and ShapeList

import java.rmi.*;

import java.util.Vector;

public interface Shape extends Remote {

int getVersion() throws RemoteException;

GraphicalObject getAllState() throws RemoteException; 1

}

public interface ShapeListextends Remote {

Shape newShape(GraphicalObject g) throws RemoteException; 2Vector allShapes() throws RemoteException;

int getVersion() throws RemoteException;

}


43/46

Java class ShapeListServant implements interface ShapeList

import java.rmi.*;

import java.rmi.server.UnicastRemoteObject;import java.util.Vector;

public class ShapeListServantextends UnicastRemoteObjectimplements ShapeList{

private Vector theList; // contains the list of Shapes 1

private int version;

public ShapeListServant()throws RemoteException{...}public Shape newShape(GraphicalObject g) throws RemoteException { 2

version++;

Shape s = new ShapeServant( g, version); 3

theList.addElement(s);

return s;

}

public Vector allShapes()throws RemoteException{...}

public int getVersion() throws RemoteException { ... }

}


44/46

Java class ShapeListServer withmain method

import java.rmi.*;public class ShapeListServer{

public static void main(String args[]){

System.setSecurityManager(new RMISecurityManager());

try{

ShapeList aShapeList= new ShapeListServant(); 1

Naming.rebind("Shape List", aShapeList ); 2

System.out.println("ShapeList server ready");

}catch(Exception e) {

System.out.println("ShapeList server main " + e.getMessage());}

}

}


45/46

Java client ofShapeList

import java.rmi.*;

import java.rmi.server.*;import java.util.Vector;

public class ShapeListClient{

public static void main(String args[]){

System.setSecurityManager(new RMISecurityManager());

ShapeListaShapeList = null;

try{

aShapeList = (ShapeList)Naming.lookup("//bruno.ShapeList") ; 1

Vector sList = aShapeList.allShapes(); 2

} catch(RemoteException e) {System.out.println(e.getMessage());

}catch(Exception e) {System.out.println("Client: " + e.getMessage());}

}

}


46/46

distributed obj and remote invocation

Documents