Chapter 5: Distributed objects and remote invocation

Introduction Communication between distributed objects Remote procedure call Events and notifications Java RMI case study Summary

Middleware
Layers of Middleware Provide a programming model Provide transparence
Location Communication protocols Computer hardware Operating systems Programming languages

Figure 5.1 Middleware Layers

Applications RMI, RPC and events Request reply protocol External data representation Operating System Middleware layers

Distributed programming model Remote procedure call (RPC)

call procedure in separate process

Remote method invocation (RMI)

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

Event-based model
Register interested events of other objects Receive notification of the events at other objects

Interfaces Interface
Specifies accessible procedures and variables Inner alteration wont affect the user of the interface

Interface in distributed system

Cant access variables directly Input argument and output argument Pointers cant be passed as arguments or returned results

Interface cases 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 or returned 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 one another.
e.g. CORBA IDL (n1), DCE IDL and DCOM IDL

CORBA IDL example

struct Person { string name; string place; CORBA has a struct remote interface long year; }; interface PersonList { remote interface defines readonly attribute string listname; methods for RMI void addPerson(in Person p) ; void getPerson(in string name, out Person p); long number(); };

parameters are in, out or inout

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

Chapter 5: Distributed objects and remote invocation

Introduction Communication between distributed objects Remote procedure call Events and notifications Java RMI case study Summary

Distributed object model

Figure 5.3
remote invocation A C E invocation local invocation local invocation D local remote invocation

each process contains objects, some of which can receive remote invocations, 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

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 the network, so this is more complex than local fault handling. Different semantics are used for reliability, involving retransmission or notification and attempting to avoid duplication.

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 reexecuted

Retransmission of Results
Determines if the results from requests should be saved and resent instead of re-executing a request

Invocation Semantics
Maybe Invocation Semantics
Remote method requests may be executed once or not at all Used when request messages are not resent when a fault occurs Requesting system cannot tell if the server executed the request before the fault occurred

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 alter the 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 times before the server starts processing new requests. The server will executes the withdraw request 5 times. The result is that instead of $10 being withdrawn, $50 is taken out of the account. This is not an acceptable result!

Invocation Semantics Cont.

At-Most-Once Invocation Semantics
Requesting system either receives a result or an exception If the requesting system receives a result, it is because the server executed the result exactly once Used when duplicate request messages are filtered out

Invocation semantics
Local invocations are executed exactly once Remote invocations cannot achieve this. Why not? the Request-reply protocol can apply fault-tolerance measures
Fault tolerance measures Retransmit request message No Yes Yes Duplicate filtering Re-execute procedure or retransmit reply Maybe Invocation semantics

Not applicable Not applicable No Yes

Re-execute procedure At-least-once Retransmit reply At-most-once

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 - if no reply, the client does not know if method was executed or not
omission failures if the invocation or result message is lost

At-least-once - the client gets a result (and the method was executed at least once) or an exception (no result)
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

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)

Communication & Remote Reference Modules

Communication Module
Transmits request and reply messages Concerned with the Message Type, requestId, and the remote reference of the 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 object message and vice versa Creates new remote object references Maintains the local to remote object references in a Remote Object Table

The architecture of remote method invocation

client object A proxy for B Request

server skeleton & dispatcher for Bs class remote object B

Reply

Communication Remote reference module module

Communication Remote reference module module

Proxy - makes RMI transparent carries out Requestto client. Class implements remote interface. Marshals requests and reply protocol unmarshals results. Forwards request. translates between local and remote Skeleton - implements methods in remote interface. object references and creates remote Dispatcher - gets request and marshals results. Invokes Unmarshals requests from communication module and object references. Uses remote object invokes method in skeleton (using methodID in message). method in remote object. table

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

Chapter 5: Distributed objects and remote invocation

Introduction Communication between distributed objects Remote procedure call Events and notifications Java RMI case study Summary

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 process Request

server process

client stub procedure client program Communication module

Reply

server stub procedure Communication dispatcher module service procedure

Sun RPC case study Binding portmapper

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

Chapter 5: Distributed objects and remote invocation

Introduction Communication between distributed objects Remote procedure call Events and notifications Java RMI case study Summary

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 system two characteristics

Heterogeneous: components in a DS that were not designed to interoperate can be made to work together Asynchronous: prevent publishers needing to synchronize with subscribers

Example - dealing room system Requirements

allow 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

Dealing room system

Dealers computer External source Notification Notification Dealers computer

Dealer

Dealer

Notification

Information provider

Notification

Notification Notification Dealers computer

Notification Dealers computer Notification

Information provider

Notification Dealer
Notification Dealer External source

Architecture for distributed event notification

Event service: maintain a database of published events and of subscribers interests decouple the publishers from the subscribers

Event service
object of interest 1. object of interest 2. object of interest 3. notification observer notification observer notification subscriber notification subscriber

subscriber

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.

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 patient monitor

Roles for observers

Forwarding
send notifications to subscribers on behalf of one or more objects of interests

Filtering of notifications according to some predicate Patterns of events Notification mailboxes

notification be delayed until subscriber being ready to receive

Jini distributed event specification EventGenerator interface

Provide register method Event generator implement it Subscriber invoke it to subscribe to the interested events

RemoteEventListener interface
Provide notify method 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 of observer

Chapter 5: Distributed objects and remote invocation

Introduction Communication between distributed objects Remote procedure call Events and notifications Java RMI case study Summary

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, nonremote serializable objects are copied and passed by value

RMIregistry
access by the Naming class

Example: shared whiteboard Remote Interface Server program and Client program Callbacks
A servers action of notifying clients about an event Implementation
Client create a remote object Client pass the remote object reference to server Whenever an event occurs, server call client via the remote object

Advantage
Improve performance by avoid constant polling Delivery information in a timely manner

Design and implementation of Java RMI

Java classes supporting RMI

RemoteObject

RemoteServer
Activatable UnicastRemoteObject <servant class>

Chapter 5: Distributed objects and remote invocation

Introduction Communication between distributed objects Remote procedure call Events and notifications Java RMI case study Summary

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

Middleware layers
Applications RMI, RPC and events Request reply protocol Middleware layers

External data representation

Operating System

A remote object and its remote interface

remote object

remote interface

Data
m4 m5 m6

m1
m2 m3

implementation of methods

Remote and local method invocations

remote

local

C local

E remote invocation

invocation B

invocation

invocation A local invocation

Files interface in Sun XDR

const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { FileIdentifier f; FilePointer position; Data data; };

struct readargs { FileIdentifier f; FilePointer position; Length length; }; program FILEREADWRITE { version VERSION { void WRITE(writeargs)=1; Data READ(readargs)=2; }=2; } = 9999;

1 2

Dealing room system

Dealers computer External source Notification Notification Dealers computer

Dealer

Dealer

Notification

Information provider

Notification

Notification Notification Dealers computer

Notification Dealers computer Notification

Information provider

Notification Dealer
Notification Dealer External source

The Naming class of Java RMIregistry

void rebind (String name, Remote obj) This method is used by a server to register the identifier of a remote object by name, as shown in Figure 15.13, line 3. void bind (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. void unbind (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.

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; }

public interface ShapeList extends Remote { Shape newShape(GraphicalObject g) throws RemoteException; 2 Vector allShapes() throws RemoteException; int getVersion() throws RemoteException; }

Java class ShapeListServant implements interface ShapeList

import java.rmi.*; import java.rmi.server.UnicastRemoteObject; import java.util.Vector; public class ShapeListServant extends UnicastRemoteObject implements 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 { ... } }

Java class ShapeListServer with main method

import java.rmi.*; public class ShapeListServer{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try{ ShapeList aShapeList = new ShapeListServant(); Naming.rebind("Shape List", aShapeList ); System.out.println("ShapeList server ready"); }catch(Exception e) { System.out.println("ShapeList server main " + e.getMessage());} } }

1 2

Java client of ShapeList

import java.rmi.*; import java.rmi.server.*; import java.util.Vector; public class ShapeListClient{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); ShapeList aShapeList = null; try{ aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ; Vector sList = aShapeList.allShapes(); } catch(RemoteException e) {System.out.println(e.getMessage()); }catch(Exception e) {System.out.println("Client: " + e.getMessage());} } }

1 2

Callback mechanism in the whiteboard system

Client created remote object:
Public interface WhiteboardCallback implements Remote{ void callback(int version) throws RemoteException; }

Methods added in Shapelist interface:

Int register(WhiteboardCallback callback) throws RemoteException; Void deregister(int callbackID) throws RemoteException;