CC Unit 5

CS 843 - Distributed Computing Systems
Chapter 5: Distributed Objects and Remote

Invocation
Chin-Chih Chang, chang@cs.twsu.edu
From Coulouris, Dollimore and Kindberg

Distributed Systems:
Concepts and Design
Edition 3, © Addison-Wesley 2001
Distributed Objects and Remote Invocation
• Topics covered in this chapter:

 Communication between distributed objects
 Remote procedure call
 Events and notification
 Java RMI
• What are issues in distributing objects?
 How can we identify objects?
 What is involved in invoking a method implemented by the
class?
o What methods are available?
o How can we pass parameters and get results?
 Can we track events in a distributed system?
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Programming Models for Distributed
Application
• Remote procedure call – client calls the
procedures in a server program that is running in
a different process
• Remote method invocation (RMI) – an object in
one process can invoke methods of objects in
another process
• Event notification – objects receive notification of
events at other objects for which they have
registered
• These mechanism must be location-transparent.
Role of Middleware
• Middleware Roles
 provide high-level abstractions such as RMI
 enable location transparency
 free from specifics of
o communication protocols
o operating systems and communication
hardware
 interoperability
Figure 5.1
Middleware layers
Applications
RMI, RPC and events

Middleware
Request reply protocol layers
External data representation
Operating System
Interfaces
• Interface – skeleton of public class
 Interaction specification
 useful abstraction that removes dependencies on internal
details
 examples
o procedure interface
o class interface
o module interface
• Distributed system interfaces
 What is the main difference from single processor
situation?
o processes at different nodes
o can only pass accessible information
Service Interface (RPC)
• Service interface
 specifies set of procedures available to client
 input and output parameters
 Remote Procedure Call
o arguments are marshaled
o marshaled packet sent to server
o server unmarshals packet, performs procedure, and
sends marshaled return packet to client
o client unmarshals the return
o all the details are transparent
Remote Interface (RMI)
• Remote interface
 specifies methods of an object available for remote
invocation
 input and output parameters may be objects
 Remote Method Invocation
o communication actual arguments marshaled and sent
to server
o server unmarshals packet, performs procedure, and
sends marshaled return packet to caller
o client unmarshals return packet
o common format definition for how to pass objects (e.g.,
CORBA IDL or Java RMI)
Interface Definition Language
• Interface Definition Language

 notation for language independent interfaces
o specify type and
o kind of parameters
 examples
o CORBA IDL for RMI
o Sun XDR for RPC
o DCOM IDL
 IDL compiler allows interoperability
CORBA IDL Example
struct Person {
string name; Figure 5.2
CORBA has a string place;
struct long year; remote interface
};
interface PersonList { remote interface
readonly attribute string listname;
defines methods for
void addPerson(in Person p) ;
void getPerson(in string name, out Person RMI
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
•
The Object Model
• An object encapsulates encapsulates both data and

methods.
• Objects can be accessed via object references.
• An interface provides a definition of the signatures
of a set of methods.
• Actions are performed by method invocations.
 The state of receiver may be changed.
 Further invocations of methods on other objects may take
place.
The Object Model
• Exceptions may be thrown to caller when an error

occurs.
• Garbage collection frees the space occupied by
objects when they are no longer needed.
The Distributed Objects Model
• Remote method invocation – Method invocations

between objects in different processes, whether in
the same computer of not.
• Local method invocation – Method invocations
between objects in the same process.
• Remote object – Objects that can receive remote
invocations.
• Remote and local method invocations are shown in
Figure 5.3.
Distributed Object Model
Figure 5.3
remote local C
invocation invocation local E
remote
invocation invocation F
B local
A
invocation D
• 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. How do they get it?
• the remote interface specifies which methods can be invoked remotely
•
Distributed Object Model
• Remote object reference

 An object must have the remote object reference of an
object in order to do remote invocation of an object
 Remote object references may be passed as input
arguments or returned as output arguments
• Remote interface
 Objects in other processes can invoke only the methods
that belong to its remote interface (Figure 5.4).
 CORBA – uses IDL to specify remote interface
 JAVA – extends interface by the Remote keyword.
Figure 5.4
A remote object and its remote interface
remoteobject
Data
remote
interface
m1 m4
{
implementation m5
m2
of methods m6
m3
Design Issues for RMI
• Two important issues in making RMI natural

extension of local method: (These problems won’t
occur in the local invocation.)
 Number of times of invocations are invoked in response
to a single remote invocation
 Level of location transparency
• Exactly once invocation semantics - Every
method is executed exactly once. (Ideal situation)
Invocation Semantics Properties
• Maybe invocation semantics:

 The invoker can not determine whether or not the remote
method has been executed.
 Types of failures:
o Omission failures if the invocation or result message is
lost.
o Crash failures when the server containing the remote
object fails.
 Useful for applications where occasional failed invocation
are acceptable.
• At-least-once invocation semantics:
 The invoker either receives a result (in which case the
user knows the method was executed at least once) or an
exception.
 Types of failures:
o Retransmitting request masks omission failures.
o Crash failures when the server containing the remote
object fails.
o Arbitrary failure when the remote method is invoked
more than once, wrong values are stored or returned.
An idempotent operation that can be performed
repeatedly with the same effect can be a solution.
 Useful if the objects in a server can be designed to have
idempotent operations.
• At-most-once invocation semantics:
 The invoker either receives a result (and the user knows
the the method was executed exactly at most once) or an
exception.
 All fault tolerance methods executed.
 Omission failures can be eliminated by retransmitting
request.
 Arbitrary failures can be prevented by ensuring that no
method is executed more than once.
• JAVA RMI and CORBA use at-most-once
semantics. CORBA also maybe semantics for
methods that do not return results. SUNRPC
provides at-least-once semantics.
Invocation Semantics
• To provide a more reliable request-reply

protocol, these fault-tolerant measures can be
employed:
 Retry request message: whether to retransmit the
request message until either a reply is received or the
server is assumed to have failed.
 Duplicate filtering: when retransmissions are used,
whether to filter out duplicate requests at the server.
 Retransmission of results: whether to keep a history of
result messages to enable lost results to be retransmitted
without re-executing the operations at the server.
• Combinations of these measures lead to a variety of

possible semantics for the reliability of remote
invocations.
• Figure 5.5 shows the measures, with corresponding
names for the invocation semantics that they
produce.
• Local invocations are executed exactly once
• Remote invocations cannot achieve this. Why not? :
 The Request-reply protocol can apply fault-tolerance
measure.
Figure 5.5 Fault tolerance measures Invocation

semantics
Retransmit request Duplicate Re-execute procedure

message filtering or retransmit reply
No Not applicable Not applicable Maybe
Yes No Re-execute procedure At-least-once
Yes Yes Retransmit reply At-most-once

•
(Location) Transparency Issues
• Goal is to make a remote invocation as similar as

possible a local invocation.
• Issues (Differences from the local invocation)
 Syntax may be made identical but behavioral differences
exists. The cause could be failure and latency.
 Interface specification
o Exceptions and exception handling are needed.
o Different invocation semantics can be employed.
Implementation of RMI
• Figure 5.6 shows an object A invokes a method in a

remote object B.
• Communication module:
 Request-Reply Protocol
 Responsible for providing selected invocation semantics
 The server selects the dispatcher for the class of the
object to be invoked.
The Architecture of Remote Method
Invocation
Figure 5.6
client server
remote
object A proxy for B skeleton
object B
Request & dispatcher
for B’s class
Reply
Remote Communication Communication Remote reference

reference module module module module
Proxy - makes RMI transparent to client. carriesClass implements

out Request-
remote interface. Marshals requests andprotocolunmarshals RMI software - between
reply
results. Forwards request. application level objects
translates
Skeleton - between local
implements and remote
methods in remote objectinterface.
and communication and
references
Unmarshals and creates
requests remote
and marshals object
Dispatcher - gets request from communication module and results. Invokes
references.
method in Uses
remote remote
object. object table remote reference modules
•
invokes method in skeleton (using methodID in message).
Remote Reference Module
• Responsibilities
 translation between local and remote object references
o remote object table
- entry for each remote object held by process
- entry for each local proxy
o arriving remote object reference - creation of remote
object references
 creation of remote object references
o need to pass a remote object - look up in remote object
table (create new remote object reference and add
entry if necessary)
RMI Software
• Proxy - provides remote invocation transparency

 marshal arguments, unmarshal results, send and receive
messages
• Dispatcher - handles transfer of requests to correct
method
 receive requests, select correct method, and pass on
request message
• Skeleton - implements methods of remote interface
 unmarshal arguments from request, invoke the method of
the remote object, and marshal the results
RMI Server and Client Programs
• Server
 classes for dispatchers, skeletons and remote objects
 initialization section for creating some remote objects
 registration of remote objects with the binder
• Client
 classes for proxies of all remote objects
 binder to look up remote object references
 cannot create remote objects by directly calling
constructors - provide factory methods instead
RMI Binder and Server Threads
• A binder in a distributed system is a separate

service that maintains a table containing mappings
from textual names to remote object references.
• Server threads
 sometimes implemented so that remote invocation causes
a new thread to be created to handle the call
 server with several remote objects might also allocate
separate threads to handle each object
o What are the advantages/disadvantages of each
approach?
o What other threading organizations could be used?
RMI Binder and Server Threads
• Activation of remote objects

 A remote object is described as active when it is a running
process.
 A remote object is described as passive when it can be
made active if requested.
• An object that can live between activations of
processes is called a persistent object.
• A location service helps clients to locate remote
objects from their remote references.
RMI Distributed Garbage Collection
• Aim - recover memory if no reference to an object

exist. If there is a reference object should still exists.
• Java distributed algorithm - based on reference
counting
• The distributed garbage collector works in
cooperation with the local garbage collector.
 Each server has a table (B.holders) that maintains list of
references to an object.
 When the client C first receives a reference to an object B,
it invokes addRef(B) and then creates a proxy. The server
adds C to the remote object holder B.holders.
RMI Distributed Garbage Collection
• The distributed garbage collection (continued):

 When remote object B is no longer reachable, it deletes
the proxy and invokes removeRef(B).
 When B.holders is empty, the server reclaim the space
occupied by B.
• Leases in Jini
 To avoid complicated protocols to discover whether a
resource are still used, the resource is leased for use for a
period of time.
 An object representing a lease implements the Lease
interface.
Remote Procedure Call Basics
• Problems with sockets

 The read/write (input/output) mechanism is used
in socket programming.
 Socket programming is different from procedure
calls which we usually use.
 To make distributed computing transparent from
locations, input/output is not the best way.
• A procedure call is a standard abstraction in local

computation.
• Procedure calls are extended to distributed
computation in Remote Procedure Call (RPC) as
shown in Figure 5.7.
 A caller invokes execution of procedure in the
callee via the local stub procedure.
 The implicit network programming hides all
network I/O code from the programmer.
 Objectives are simplicity and ease of use.
Figure 5.7
Role of client and server stub procedures in RPC
client process server process
Request
Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module dispatcher
• The concept is to provide a transparent mechanism

that enables the user to utilize remote services
through standard procedure calls.
• Client sends request, then blocks until a remote
server sends a response (reply).
• Advantages: user may be unaware of remote
implementation (handled in a stub in library); uses
standard mechanism.
• Disadvantages: prone to failure of components and
network; different address spaces; separate process
lifetimes.
• Differences with respect to message passing:

 Message passing systems are peer-to-peer while RPC is
more master/slave.
 In message passing the calling process creates the
message while in RPC the system create the message.
• Semantics of RPC:
 Caller blocks.
 Caller may send arguments to remote procedure.
 Callee may return results.
 Caller and callee access different address spaces.
Sun RPC
• It is designed for client-server communication over

Sun NFS network file system.
• UDP or TCP can be used. If UDP is used, the
message length is restricted to 64 KB, but 8 - 9 KB
in practice.
• The Sun XDR is originally intended for external data
representation.
• Valid data types supported by XDR include int,
unsigned int, long, structure, fixed array, string
(null terminated char *), binary encoded data (for
other data types such as lists).
Interface Definition Language
• The notation is rather primitive compared to CORBA

IDL or JAVA as shown in Figure 5.8.
 Instead of no interface definition, a program
number and a version number are supplied.
 The procedure number is used as a procedure
definition.
 Single input parameter and output result are being
passed.
Figure 5.8
Files interface in Sun XDR
const MAX = 1000;

typedef int FileIdentifier;
typedef int FilePointer;
typedef int Length; struct readargs {
struct Data { FileIdentifier f;
int length; FilePointer position;
char buffer[MAX]; Length length;
}; };
struct writeargs {
FileIdentifier f; program FILEREADWRITE {
FilePointer position; version VERSION {
Data data; void WRITE(writeargs)=1; 1
}; Data READ(readargs)=2; 2
}=2;
} = 9999;
Sun RPC
• The interface compiler rpcgen can be used to
generate the following from interface definition.
 client stub procedures
 server main procedure, dispatcher and server stub
procedures
 XDR marshalling and unmarshalling procedures used
by dispatcher and client, server stub procedures.
• Binding:
 portmapper records program number, version number,
and port number.
 If there are multiple instance running on different
machines, clients make multicast remote procedure calls
by broadcasting them to all the port mappers.
RPC Interface Compiler
Sun RPC
• Authentication:
 Additional fields are provided in the request-reply
message.
 Server program should check the authentication and then
execute.
 Different authentication protocols can be supported - none,
UNIX style, shared key, Kerberos style.
 A field in RPC header indicates which style is used.
Example (Sun RPC)
• long sum(long) example

 client localhost 10
 result: 55
• Need RPC specification file (sum.x)
 defines procedure name, arguments & results
• Run (interface compiler) rpcgen sum.x
 generates sum.h, sum_clnt.c, sum_xdr.c, sum_svc.c
 sum_clnt.c & sum_svc.c: Stub routines for client & server
 sum_xdr.c: XDR (External Data Representation) code
takes care of data type conversions
RPC IDL File (sum.x)
struct sum_in {
long arg1;
};
struct sum_out {
long res1;
};
program SUM_PROG {
version SUM_VERS {
sum_out SUMPROC(sum_in) = 1; /* procedure number = 1*/
} = 1; /* version number = 1 */
} = 0x32123000; /* program number */
Example (Sun RPC)
• Program-number is usually assigned as follows:

 0x00000000 - 0x1fffffff defined by SUN
 0x20000000 - 0x3fffffff defined by user
 0x40000000 - 0x5fffffff transient
 0x60000000 - 0xffffffff reserved
RPC Client Code (rsum.c)
#include ''sum.h''
main(int argc, char* argv[]) {
CLIENT* cl; sum_in in; sum_out *outp;
// create RPC client handle; need to know server's address
cl = clnt_create(argv[1], SUM_PROG, SUM_VERS, ''tcp'');
in.arg1 = atol(argv[2]); // number to be squared
// Call RPC; note convention of RPC function naming
if ( (outp = sumproc_1(&in, cl)) == NULL)
err_quit(''%s'', clnt_sperror(cl, argv[1]);
printf(''result: %ld\n'', outp->res1);
}
RPC Server Code (sum_serv.c)
#include "sum.h"
sum_out* sumproc_1_svc (sum_in *inp, struct svc_req *rqstp)
{ // server function has different name than client call
static sum_out out; // why is this static?
int i;
out.res1 = inp->arg1;
for (i = inp->arg1 - 1; i > 0; i--)
out.res1 += i;
return(&out);
}
// server's main() is generated by rpcgen
Compilation Linking
rpcgen sum.x
cc -c rsum.c -o rsum.o
cc -c sum_clnt.c -o sum_clnt.o
cc -c sum_xdr.c -o sum_xdr.o
cc -o client rsum.o sum_clnt.o sum_xdr.o
cc -c sum_serv.c -o sum_serv.o
cc -c sum_svc.c -o sum_svc.o
cc -o server sum_serv.o sum_svc.o sum_xdr.o
Internal Details of Sun RPC
• Initialization
 Server runs: register RPC with port mapper on server host
(rpcinfo –p)
 Client runs: clnt_create contacts server's port mapper
and establishes TCP connection with server (or UDP
socket)
• Client
 Client calls local procedure (client stub: sumproc_1), that
is generated by rpcgen. Client stub packages arguments,
puts them in standard format (XDR), and prepares network
messages (marshaling).
 Network messages are sent to remote system by client
stub.
 Network transfer is accomplished with TCP or UDP.
Internal Details of Sun RPC
• Server
 Server stub (generated by rpcgen) unmarshals arguments
from network messages. Server stub executes local
procedure (sumproc_1_svc) passing arguments received
from network messages.
 When server procedure is finished, it returns to server stub
with return values.
 Server stub converts return values (XDR), marshals them
into network messages, and sends them back to client
• Back to Client
 Client stub reads network messages from kernel
 Client stub returns results to client function
Details of RPC
RPC Issues
• Uniform call semantics - Calling semantics must

be same whether procedure is implemented locally
or remotely.
 Exactly once: It is hard to achieve in practice.
 At most once: It requests RPC only once (no reply may
mean that no execution tooks place)
 At least once: It keeps requesting RPC until valid
response arrives at client.
 RPC is inappropriate for nonidempotent operations.
• Type checking - Level of static type checking used
for local calls should be the same as that for remote
calls.
RPC Issues
• Full parameter functionality - All basic data types

should be allowed; this includes but is not limited to:
primitive types, structured types, and user defined
types.
• Concurrency control and exception handling -
Although not a direct portion of RPC, the
programming language that provide RPC must
support these services.
RPC Issues
• Distributed binding - Programming language must

be able to compile, bind and load distributed
program onto the network
• Orphan Computations
 This involves recovery from failed RPC
 It can use extermination to find and abort orphan
computations.
 It can use expiration to terminate a computation that
exceeds its expected lifetime.
Events and Notifications
• The idea behind the use of events is that one object

can react to a change occurring in another object.
• The actions done by the user are seen as events
that cause state changes in objects.
• The objects are notified whenever the state
changes.
• Local event model can be extended to distributed
event-based systems by using the publish-
subscribe paradigm.
• In publish-subscribe paradigm
 An object that has event publishes.
 Those that have interest subscribe.
• Objects that represent events are called
notifications.
• Distributed event-based systems have two main
characteristics:
 Heterogeneous – Event-based systems can be used to
connect heterogeneous components in the Internet.
 Asynchronous – Notification are sent asynchronously by
event-generating objects to those subscribers.
• A dealing room system could be modeled by

processes with two different tasks (Figure 5.9):
 An information provider process continuously receives
new trading information from a single external source and
applies to the appropriate stock objects.
 A dealer process creates an object to represent each
named stock that the user asks to have displayed.
• An event source can generate events of one more
different types. Each event has attributes that
specify information about that event.
Figure 5.9
Dealing room system
Dealer’s computer External Dealer’s computer

source
Dealer Notification Notification Dealer
Notification Information
provider Notification
Notification
Notification
Notification
Dealer’s computer Dealer’s computer
Notification
Information
provider
Notification
Dealer Notification
Dealer
External
source
• The architecture of distributed event notification

specifies the roles of participants as in Fig. 5.10:
 It is designed in a way that publishers work
independently from subscribers.
 Event service maintains a database of published
events and of subscribers’ interests.
• The roles of the participants are:
 Object of Interest – This is an object experiences
changes of state, as a result of its operations being
invoked.
• The roles of the participants are (continued):

 Event – An event occurs at an object of interest as the
result of the completion of a method invocation.
 Notification – A notification is an object that contains
information about an event.
 Subscriber – A subscriber is an object that has
subscribed to some type of events in another object.
 Observer objects – The main purpose of an observer
is to separate an object of interest from its subscribers.
 Publisher – This is an object that declares that it will
generate notifications of particular types of event.
• Figure 5.10 shows three cases:

1. An object of interest inside the event service sends
notification directly to the subscribers.
2. An object of interest inside the event service sends
notification via the observer to the subscribers.
3. The observer queries the object of interest outside the
event service and sends notifications to the
subscribers.
Figure 5.10
Architecture for distributed event notification
Event service
object of interest subscriber
1. notification
object of interest observer subscriber
2. notification notification
object of interest observer subscriber
3. notification
• A variety of delivery semantics can be

employed:
 IP multicast protocol – information delivery on the
latest state of a player in an Internet game
 Reliable multicast protocol – information provider /
dealer
 Totally ordered multicast - Computer Supported
Cooperative Working (CSCW) environment
 Real-time – nuclear power station / hospital patient
monitor
• Roles for observers – the task of processing

notifications can be divided among observers:
 Forwarding – Observers simply forward notifications
to subscribers.
 Filtering of notifications – Observers address
notifications to those subscribers who find these
notifications are useful.
 Patterns of events – Subscribers can specify
patterns of events of interest.
 Notification mailboxes – A subscriber can set up a
notification mailbox which receives the notification on
behalf of the subscriber.
Jini Distributed Event Specification
• Jini network technology is an open spontaneous

network architecture that enables developers to
create network-centric services - whether
implemented in hardware or software - that are
highly adaptive to change.
• Jini’s distributed events specification allows a
potential subscriber in one Java Virtual
Machine(JVM) to subscribe to and receive
notifications of events in an object of interest in
another JVM.
Jini Distributed Event Specification
• Main objects:
 Event generators - It is an object that allows other
objects to subscribe to its events and generates
notifications.
 Remote event listeners - A remote event listener is an
object that can receive notifications.
 Remote events - A remote event is an object that is
passed by value to remote event listeners. It is equivalent
to a notification.
 Third party agents - Third party agents may be
interposed between an object of interest and a subscriber.
Interfaces and Classes
• Jini events are provided by means of the following

interfaces and classes:
 RemoteEventListener - The RemoteEventListener
interface needs to be implemented by any object that
wants to receive a notification of a remote event from
some other object.
 RemoteEvent - The base class or superclass for remote
events.
 EventRegistration - A utility class for use as a return
value for event-interest registration methods.
• For more details, refer to Jini online document.
Java RMI
• Java RMI extends the Java object model to provide

support for distributed objects in the Java language.
 It allows objects to invoke methods on remote objects
using the same syntax as for local invocations.
 Type checking applies equally to remote invocations as to
local ones.
 The remote invocation is known because
RemoteExceptions has been handled and the remote
object is implemented using the Remote interface.
 The semantics of parameter passing differ because
invoker and target are remote from on another.
Java RMI
• Programming distributed applications in Java RMI is

simple.
 It is a single-language system.
 The programmer of a remote object must consider its
behavior in a concurrent environment.
• The files needed for creating a Java RMI application
are:
 A remote interface defines the remote interface provided
by the service. Usually, it is a single line statement
specifies the service function (HelloInterface.java). (An
interface is the skeleton for a public class.)
Java RMI
• The files needed for creating a Java RMI application

are (continued):
 A remote object implements the remote service. It
contains a constructor and required functions. (Hello.java)
 A client that invokes the remote method.
(HelloClient.java)
 The server offers the remote service, installs a security
manager and contacts rmiregistry with an instance of the
service under the name of the remote object.
(HelloServer.java)
HelloInterface.java
import java.rmi.*;
public interface HelloInterface extends Remote {

public String say(String msg) throws
RemoteException;
}
Hello.java
import java.rmi.*;
import java.rmi.server.*;
public class Hello extends
UnicastRemoteObject implements HelloInterface {
private String message;
public Hello(String msg) throws RemoteException {

message = msg;
}
Hello.java (continued)
public String say(String m) throws RemoteException {

// return input message - reversing input and suffixing
// our standard message
return new StringBuffer(m).reverse().toString() + "\n" +
message;
}
}
HelloClient.java
import java.rmi.*;
public class HelloClient {

public static void main(String args[]) {
String path = "//localhost/Hello";
try {
if (args.length < 1) {
System.out.println("usage: java HelloClient
<host:port> <string> ... \n");
} else path = "//" + args[0] + "/Hello";
HelloClient.java
HelloInterface hello =
(HelloInterface) Naming.lookup(path);
for (int i = 0; i < args.length; ++i)
System.out.println(hello.say(args[i]));
} catch(Exception e) {
System.out.println("HelloClient exception: " + e);
}
}
}
HelloServer.java
import java.rmi.*;
public class HelloServer {

public static void main(String args[]) {
// Create and install a security manager
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
try {
Naming.rebind("Hello", new Hello("Hello, world!"));
System.out.println("server is running...");
}
HelloServer.java
catch (Exception e) {
System.out.println("Hello server failed:" + e.getMessage());
}
}
}
Java RMI
• Compile the code

javac Hello.java HelloClient.java
HelloInterface.java HelloServer.java
• Generate stubs for the remote service
(make sure that your classpath contains your current
directory)
rmic Hello
• Start the registry (in a separate window or in the
background)
rmiregistry
(be sure to kill this process when you're done)
Java RMI
• Start the server in one window or in the background

with the security policy
java -Djava.security.policy=policy HelloServer
or without the security policy
java HelloServer
• Run the client in another window
java HelloClient testing
Java RMI Remote Object References
• An object must have the remote object reference of
other object in order to do remote invocation of that
object.
• Parameter and result passing
 Remote object references may be passed as input
arguments or returned as output arguments.
 Parameters of a method in Java are input parameters.
 Returned result of a method in Java is the single output
parameter.
 Objects are serialized to be passed as parameters.
 When a remote object reference is returned, it can be
used to invoke remote methods.
 Local serializable objects are copied by value.
• Downloading of classes
 Java is designed to allow classes to be downloaded from
one virtual machine to another.
 If the recipient of a remote object reference does not
posses the proxy class, its code is downloaded
automatically.
• RMIregistry
 The RMIregistry is designed to allow is the binder for Java
RMI.
 It maintains a table mapping textual, URL-style names to
references to remote objects.
• Server Program
 The server consists of a main method and a servant class
to implement each of its remote interface.
 The main method of a server needs to create a security
manager to enable Java security to apply the protection for
an RMI server.
• Client Program
 Any client program needs to get started by using a binder
to look up a remote reference.
 A client can set a security manager and then looks up a
remote object reference.
Java RMI Callbacks
• Callback refers to server's action in notifying the

client.
• Callback Facility - Instead of client polling the
server, the server calls a method in the client when it
is updated.
• Details
 Client creates a remote object that implements an
interface for the server to call.
 The server provides an operation for clients to register
their callbacks.
 When an event occurs, the server calls the interested
clients.
Java RMI Callback Issues
• Advantages of callback
 more efficient than polling
 more timely than polling
 provides a way for the server to inquire about client status
• Disadvantages of callback
 may leave server in inconsistent state if client crashes or
exits without notifying server
 requires server to make series of synchronous RMI's
Shared Whiteboard Example
• In the RMI and CORBA case studies, we use a

shared whiteboard as an example
 This is a distributed program that allows a group of users
to share a common view of a drawing surface containing
graphical objects, each of which has been drawn by one of
the users.
• The server maintains the current state of a drawing
and it provides operations for clients to:
 Add a shape, retrieve a shape or retrieve all the shapes,
 Retrieve its version number or the version number of a
shape
•
Figure 5.11
Java Remote interfaces Shape and ShapeList
• Note the interfaces and arguments

• GraphicalObject is a class that implements Serializable.
import java.rmi.*; Figure 5.11

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;
Vector allShapes() throws RemoteException;
int getVersion() throws RemoteException;
•
} Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Figure 5.12
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.
Figure 5.13
Java class ShapeListServer with main method
import java.rmi.*;
public class ShapeListServer{
public static void main(String args[]){
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());}
}
}
Figure 5.14
Java class ShapeListServant implements interface ShapeList
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
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 { ... }
} Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
Figure 5.15
Java client of ShapeList
import java.rmi.*;
public class ShapeListClient{
public static void main(String args[]){
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());}
}
}
Figure 5.16
Classes supporting Java RMI
RemoteObject
RemoteServer
Activatable UnicastRemoteObject
<servant class>
RMI Summary
• Each object has a (global) remote object reference

and a remote interface that specifies which of its
operations can be invoked remotely.
• Local method invocations provide exactly-once
semantics; the best RMI can guarantee is at-most-
once.
• Middleware components (proxies, skeletons and
dispatchers) hide details of marshalling, message
passing and object location from programmers.
•

CC Unit 5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CC Unit 5

Uploaded by

Copyright:

Available Formats

CS 843 - Distributed Computing Systems

Chapter 5: Distributed Objects and Remote

From Coulouris, Dollimore and Kindberg

• Topics covered in this chapter:

RMI, RPC and events

External data representation

• Interface Definition Language

• An object encapsulates encapsulates both data and

• Exceptions may be thrown to caller when an error

• Remote method invocation – Method invocations

• each process contains objects, some of which can receive remote

• Remote object reference

• Two important issues in making RMI natural

• Maybe invocation semantics:

• To provide a more reliable request-reply

• Combinations of these measures lead to a variety of

Figure 5.5 Fault tolerance measures Invocation

Retransmit request Duplicate Re-execute procedure

Yes Yes Retransmit reply At-most-once

• Goal is to make a remote invocation as similar as

• Figure 5.6 shows an object A invokes a method in a

Remote Communication Communication Remote reference

Proxy - makes RMI transparent to client. carriesClass implements

• Proxy - provides remote invocation transparency

• A binder in a distributed system is a separate

• Activation of remote objects

• Aim - recover memory if no reference to an object

• The distributed garbage collection (continued):

• Problems with sockets

• A procedure call is a standard abstraction in local

client process server process

• The concept is to provide a transparent mechanism

• Differences with respect to message passing:

• It is designed for client-server communication over

• The notation is rather primitive compared to CORBA

const MAX = 1000;

• long sum(long) example

• Program-number is usually assigned as follows:

• Uniform call semantics - Calling semantics must

• Full parameter functionality - All basic data types

• Distributed binding - Programming language must

• The idea behind the use of events is that one object

• A dealing room system could be modeled by

Dealer’s computer External Dealer’s computer

Dealer Notification Notification Dealer

• The architecture of distributed event notification

• The roles of the participants are (continued):

• Figure 5.10 shows three cases:

object of interest observer subscriber

object of interest observer subscriber

• A variety of delivery semantics can be

• Roles for observers – the task of processing

• Jini network technology is an open spontaneous

• Jini events are provided by means of the following

• Java RMI extends the Java object model to provide

• Programming distributed applications in Java RMI is

• The files needed for creating a Java RMI application

public interface HelloInterface extends Remote {

public Hello(String msg) throws RemoteException {

public String say(String m) throws RemoteException {

public class HelloClient {

public class HelloServer {

• Compile the code