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
Middleware layers 
Applications 
Middleware 
RMI, RPC and events 
Request reply protocol layers 
External data representation 
Operating System
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 (n1), DCE IDL and DCOM IDL
CORBA IDL example 
struct Person { 
string name; 
string place; 
long year; 
CORBA has a struct 
} ; 
interface PersonList { 
remote interface 
remote interface defines 
methods for RMI 
readonly attribute string listname; 
void addPerson(in Person p) ; 
void getPerson(in string name, out Person p); 
long number(); 
}; 
• Remote interface: 
parameters are in, out or inout 
– 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 
remote 
invocation invocation 
remote 
invocation 
local 
local 
invocation 
local 
invocation 
Figure 5.3 
A 
B 
C 
D 
E 
F 
• 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
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 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 
Maybe 
At-least-once 
Retransmit reply At-most-once
Remote and local method invocations 
remote 
invocation invocation 
remote 
invocation 
local 
local 
invocation 
local 
invocation 
A 
B 
C 
D 
E 
F
A remote object and its remote interface 
remote 
interface 
m1 
m2 
m3 
m4 
m5 
m6 
remoteobject 
Data 
implementation 
{ of methods
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 
skeleton 
object A object B 
Request 
proxy for B 
Reply 
& dispatcher 
for B’s class 
Remote Communication Communication Remote reference 
reference module module module module 
remote 
client server 
Proxy - makes RMI transparent carries to client. out Class 
Request-reply 
implements remote interface. Marshals protocol 
requests and 
unmarshals results. Forwards request. 
Skeleton - implements methods in remote interface. 
Unmarshals requests and marshals results. Invokes 
method in remote object. 
translates between local and remote 
object references and creates remote 
object references. Uses remote object 
table 
RMI software - between 
application level objects 
and communication and 
remote reference 
modules 
Dispatcher - gets request from communication module and 
invokes method in skeleton (using methodID in message).
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 
client process server process 
Request 
Reply 
Communication Communication 
module module dispatcher 
service 
client stub server stub 
procedure procedure 
program 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 
stocks 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 
Dealer’s computer 
External 
source 
Information 
provider 
Notification 
Information 
provider 
Dealer 
External 
source 
Dealer 
Dealer 
Dealer 
Notification 
Notification 
Notification 
Notification 
Notification 
Notification 
Notification 
Notification 
Notification 
Dealer’s computer 
Dealer’s computer Dealer’s computer
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 
object of interest observer 
subscriber 
subscriber 
notification 
notification 
object of interest observer subscriber 
3. 
1. 
2. notification 
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 
• 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, non-remote 
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 
RemoteObject 
RemoteServer 
UnicastRemoteObject 
<servant class> 
Activatable
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
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; 1 
Data READ(readargs)=2; 2 
}=2; 
} = 9999;
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; 1 
} 
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(); 1 
Naming.rebind("Shape List", aShapeList ); 2 
System.out.println("ShapeList server ready"); 
}catch(Exception e) { 
System.out.println("ShapeList server main " + e.getMessage());} 
} 
}
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") ; 1 
Vector sList = aShapeList.allShapes(); 2 
} catch(RemoteException e) {System.out.println(e.getMessage()); 
}catch(Exception e) {System.out.println("Client: " + e.getMessage());} 
} 
}
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;

Ds objects and models

  • 1.
    Chapter 5: Distributedobjects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary
  • 2.
    Middleware • Layersof Middleware • Provide a programming model • Provide transparence – Location – Communication protocols – Computer hardware – Operating systems – Programming languages
  • 3.
    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
  • 4.
    Middleware layers Applications Middleware RMI, RPC and events Request reply protocol layers External data representation Operating System
  • 5.
    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
  • 6.
    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 (n1), DCE IDL and DCOM IDL
  • 7.
    CORBA IDL example struct Person { string name; string place; long year; CORBA has a struct } ; interface PersonList { remote interface remote interface defines methods for RMI readonly attribute string listname; void addPerson(in Person p) ; void getPerson(in string name, out Person p); long number(); }; • Remote interface: parameters are in, out or inout – 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
  • 8.
    Chapter 5: Distributedobjects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary
  • 9.
    Distributed object model remote invocation invocation remote invocation local local invocation local invocation Figure 5.3 A B C D E F • 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
  • 10.
    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 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 Maybe At-least-once Retransmit reply At-most-once
  • 11.
    Remote and localmethod invocations remote invocation invocation remote invocation local local invocation local invocation A B C D E F
  • 12.
    A remote objectand its remote interface remote interface m1 m2 m3 m4 m5 m6 remoteobject Data implementation { of methods
  • 13.
    Invocation semantics: failuremodel • 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)
  • 14.
    The architecture ofremote method invocation skeleton object A object B Request proxy for B Reply & dispatcher for B’s class Remote Communication Communication Remote reference reference module module module module remote client server Proxy - makes RMI transparent carries to client. out Class Request-reply implements remote interface. Marshals protocol requests and unmarshals results. Forwards request. Skeleton - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object. translates between local and remote object references and creates remote object references. Uses remote object table RMI software - between application level objects and communication and remote reference modules Dispatcher - gets request from communication module and invokes method in skeleton (using methodID in message).
  • 15.
    Chapter 5: Distributedobjects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary
  • 16.
    RPC is verysimilar 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 client process server process Request Reply Communication Communication module module dispatcher service client stub server stub procedure procedure program procedure
  • 17.
    Sun RPC casestudy • 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
  • 18.
    Sun RPC casestudy …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
  • 19.
    Chapter 5: Distributedobjects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary
  • 20.
    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
  • 21.
    Example - dealingroom system • Requirements – allow dealers to see the latest market price of the stocks 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
  • 22.
    Dealing room system Dealer’s computer External source Information provider Notification Information provider Dealer External source Dealer Dealer Dealer Notification Notification Notification Notification Notification Notification Notification Notification Notification Dealer’s computer Dealer’s computer Dealer’s computer
  • 23.
    Architecture for distributedevent notification • Event service: maintain a database of published events and of subscribers’ interests • decouple the publishers from the subscribers Event service object of interest object of interest observer subscriber subscriber notification notification object of interest observer subscriber 3. 1. 2. notification notification
  • 24.
    The roles ofthe 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.
  • 25.
    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
  • 26.
    Jini distributed eventspecification • 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
  • 27.
    Chapter 5: Distributedobjects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary
  • 28.
    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 the Naming class
  • 29.
    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
  • 30.
    Design and implementationof Java RMI • Java classes supporting RMI RemoteObject RemoteServer UnicastRemoteObject <servant class> Activatable
  • 31.
    Chapter 5: Distributedobjects and remote invocation • Introduction • Communication between distributed objects • Remote procedure call • Events and notifications • Java RMI case study • Summary
  • 32.
    Summary • Twoparadigms 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
  • 33.
    Files interface inSun 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; 1 Data READ(readargs)=2; 2 }=2; } = 9999;
  • 34.
    The Naming classof 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.
  • 35.
    Java Remote interfacesShape 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 ShapeList extends Remote { Shape newShape(GraphicalObject g) throws RemoteException; 2 Vector allShapes() throws RemoteException; int getVersion() throws RemoteException; }
  • 36.
    Java class ShapeListServantimplements 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 { ... } }
  • 37.
    Java class ShapeListServerwith main 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());} } }
  • 38.
    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()); ShapeList aShapeList = 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());} } }
  • 39.
    Callback mechanism inthe 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;