Chapter 5 Distributed objects and remote invocation Introduction

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

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 won’t affect the user of the interface • Interface in distributed system – Can’t access variables directly – Input argument and output argument – Pointers can’t be passed as arguments or returned results

Interface cases • RPC’s Service interface – specification of the procedures of the server, defining the types of the input and output arguments of each procedure • RMI’s 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 (n 1), DCE IDL and DCOM IDL

CORBA IDL example struct Person { string name; string place; CORBA has a struct remote interface long year; }; interface Person. List { remote interface defines readonly attribute string listname; methods for RMI void add. Person(in Person p) ; void get. Person(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 local remote invocation A B C E invocation local invocation D 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 F

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 Duplicate message filtering Invocation semantics Re-execute procedure or retransmit reply No Not applicable Maybe Yes No Re-execute procedure At-least-once Yes 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)

The architecture of remote method invocation server client object A proxy for B Request skeleton & dispatcher for B’s class remote object B Reply Communication Remote reference module Proxy - makes RMI transparent carries to client. out Class Requestimplements remote interface. Marshals requests and reply protocol unmarshals results. Forwards request. translates between local and remote Skeleton - implements methods in remote interface. object references andfrom creates remote module and Dispatcher - gets request communication Unmarshals requests and marshals results. Invokes object method references. Uses(using remote object in message). invokes in skeleton method. ID 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 server process Request client program client stub procedure Communication module Reply server stub procedure Communication dispatcher module service procedure

Sun RPC case study • Designed for NFS – at-least-once semantics • XDR - Interface definition language – Interface name: Program number, version number – Procedure identifier: procedure number • Rpcgen – generator of RPC components – – – client stub procedure server main procedure Dispatcher server stub procedure marshalling and unmarshalling procedure

Sun RPC case study …continued • 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

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 subscriber object of interest 1. notification object of interest 2. object of interest 3. notification observer subscriber notification

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 • Event. Generator interface – Provide register method – Event generator implement it – Subscriber invoke it to subscribe to the interested events • Remote. Event. Listener interface – Provide notify method – subscriber implement it – receive notifications when the notify method is invoked • Remote. Event – 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 server’s 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 Remote. Object Remote. Server Activatable Unicast. Remote. Object <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 External data representation Operating System Middleware layers

A remote object and its remote interface remoteobject Data remote interface { m 1 implementation m 2 m 3 of methods m 4 m 5 m 6

Remote and local method invocations remote invocation local C invocation local invocation A B local invocation D E remote invocation F

Files interface in Sun XDR const MAX = 1000; typedef int File. Identifier; typedef int File. Pointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { File. Identifier f; File. Pointer position; Data data; }; struct readargs { File. Identifier f; File. Pointer position; Length length; }; program FILEREADWRITE { version VERSION { void WRITE(writeargs)=1; Data READ(readargs)=2; } = 9999; 1 2

Dealing room system External source Dealer’s computer Dealer Notification Dealer’s computer Notification Information provider Notification Dealer Notification Dealer’s computer Notification Information provider 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 Shape. List import java. rmi. *; import java. util. Vector; public interface Shape extends Remote { int get. Version() throws Remote. Exception; Graphical. Object get. All. State() throws Remote. Exception; } 1 public interface Shape. List extends Remote { Shape new. Shape(Graphical. Object g) throws Remote. Exception; 2 Vector all. Shapes() throws Remote. Exception; int get. Version() throws Remote. Exception; }

Java class Shape. List. Servant implements interface Shape. List import java. rmi. *; import java. rmi. server. Unicast. Remote. Object; import java. util. Vector; public class Shape. List. Servant extends Unicast. Remote. Object implements Shape. List { private Vector the. List; // contains the list of Shapes 1 private int version; public Shape. List. Servant()throws Remote. Exception{. . . } public Shape new. Shape(Graphical. Object g) throws Remote. Exception { 2 version++; Shape s = new Shape. Servant( g, version); 3 the. List. add. Element(s); return s; } public Vector all. Shapes()throws Remote. Exception{. . . } public int get. Version() throws Remote. Exception {. . . } }

Java class Shape. List. Server with main method import java. rmi. *; public class Shape. List. Server{ public static void main(String args[]){ System. set. Security. Manager(new RMISecurity. Manager()); try{ Shape. List a. Shape. List = new Shape. List. Servant(); Naming. rebind("Shape List", a. Shape. List ); System. out. println("Shape. List server ready"); }catch(Exception e) { System. out. println("Shape. List server main " + e. get. Message()); } } } 1 2

Java client of Shape. List import java. rmi. *; import java. rmi. server. *; import java. util. Vector; public class Shape. List. Client{ public static void main(String args[]){ System. set. Security. Manager(new RMISecurity. Manager()); Shape. List a. Shape. List = null; try{ a. Shape. List = (Shape. List) Naming. lookup("//bruno. Shape. List") ; Vector s. List = a. Shape. List. all. Shapes(); } catch(Remote. Exception e) {System. out. println(e. get. Message()); }catch(Exception e) {System. out. println("Client: " + e. get. Message()); } } } 1 2

Callback mechanism in the whiteboard system Client created remote object: Public interface Whiteboard. Callback implements Remote{ void callback(int version) throws Remote. Exception; } Methods added in Shapelist interface: Int register(Whiteboard. Callback callback) throws Remote. Exception; Void deregister(int callback. ID) throws Remote. Exception;