Distributed Objects

04/15/24 1
Message Passing vs. Distributed
Objects

04/15/24 2
 Message Passing versus Distributed Objects

 The message-passing paradigm is a natural model for

distributed computing, in the sense that it mimics
interhuman communications. It is an appropriate
paradigm for network services where processes interact
with each other through the exchanges of messages.
 However, the abstraction provided by this paradigm
does not meet the needs of the complexity of
sophisticated network applications.

04/15/24 3
 Message Passing versus Distributed Objects –2
 Message passing requires the participating processes to be
tightly-coupled: throughout their interaction, the processes
must be in direct communication with each other. If
communication is lost between the processes (due to failures
in the communication link, in the systems, or in one of the
processes), the collaboration fails.
 The message-passing paradigm is data-oriented. Each
message contains data marshalled in a mutually agreed upon
format, and is interpreted as a request or response according
to the protocol. (e.g., 1000-character message)
 The receiving of each message triggers an action in the
receiving process. It is inadequate for complex applications
involving a large mix of requests and responses. In such an
application, the task of interpreting the messages can become
overwhelming.
04/15/24 4
 The distributed object paradigm

 The distributed object paradigm is a paradigm that provides

abstractions beyond those of the message-passing model. As its
name implies, the paradigm is based on objects that exist in a
distributed system.
 In object-oriented programming, objects are used to represent
an entity significant to an application. Each object
encapsulates:
 the state or data of the entity: in Java, such data is contained

in the instance variables of each object;

 the operations of the entity, through which the state of the

entity can be accessed or updated.

04/15/24 5
 object-oriented programming
To illustrate, consider objects of the DatagramMessage class. Each
object instantiated from this class contains three state data items--a
message, the sender’s address, and the sender’s port number. In
addition, each object contains four operations:
 a method putVal, which allows the values of these data

items to be modified,
 a getMessage method, which allows the current value of the

message to be retrieved, and

 a getAddress method, which allows the sender’s address to

be retrieved.
 a getPort method, which allows the sender’s port to be

retrieved.

04/15/24 6
 object-oriented programming
public class DatagramMessage{
private String message;
private InetAddress senderAddress;
private int senderPort;

public void putVal(String message, InetAddress addr, int port) {

this.message = message;
this.senderAddress = addr;
this.senderPort = port; }

public String getMessage( ) {

return this.message; }

public InetAddress getAddress( ) {

return this.senderAddress; }

public int getPort( ) {

return this.senderPort; }
} // end class
04/15/24 7
 Local Objects vs. Distributed Objects

 Local objects are those whose methods can only

be invoked by a local process, a process that
runs on the same computer on which the object
exists.
 A distributed object is one whose methods can
be invoked by a remote process, a process
running on a computer connected via a network
to the computer on which the object exists.

04/15/24 8
The Distributed Object Paradigm
In a distributed object paradigm, network resources are
represented by distributed objects. To request services from a
network resource, a process invokes one of its operations or
methods, passing data as arguments to the method. The method
is executed on the remote host, and the response, if any, is
sent back to the requesting process as a returned value.
Host A Host B

clie n t pro ce s s
m e t h o d ca ll

o b je c t s t a t e d a t a i t e m
o b je c t o p e r a t i o n

04/15/24 a d i s t r i b u t e d o b je c t 9
 Message Passing versus Distributed Objects

Compared to the message-passing paradigm,

which is data-oriented, the distributed objects
paradigm is action-oriented: the focus is on the
invocation of the operations/methods, while the
data passed takes on a secondary role. Although
less intuitive to human-beings, the distributed-
object paradigm is more natural to object-oriented
software development.

04/15/24 10
 The Distributed Object Paradigm - 2
 A process running in host A makes a method call
to a distributed object residing on host B, passing
with the data as arguments, if any.
 The method call invokes an action performed by
the method on host B, and a returned value, if any,
is passed from host B to host A.
 A process which makes use of a distributed
object is said to be a client process of that
object, and the methods of the remote object are
called remote methods (as opposed to local
methods, or methods belonging to a local object)
to the client process.

04/15/24 11
The Distributed Objects
Paradigm

04/15/24 12
 An Archetypal Distributed Objects System

o b je c t
re g is t ry

o b je c t c l i e n t o b je c t s e r v e r

clie n t s e rv e r
pro x y pro x y
ru n t im e ru n t im e
s u ppo rt s u ppo rt

n e two rk n e two rk
s u ppo rt s u ppo rt

ph y s ica l da t a pa t h

lo g ica l da t a pa t h

Server Objects need to be registered in an object registry, e.g., RMI registry.

04/15/24 13
 Distributed Object System - 1
 A distributed object is provided/registered, by a
process--object server.
 A facility, here called an object registry, must be
present in the system architecture for the distributed
object to be registered.
 To access a distributed object, a process –an object
client – looks up the object registry for a reference[1]
to the object. This object reference will be used by
the object client to make calls to the methods.
[1] A reference is a “handle” for an object; it is a representation through
which an object can be located in the computer where the object resides.

04/15/24 14
 Distributed Object System - 2
 Logically, the object client makes a call directly to a
remote method.
 In reality, the call is handled by a software
component, called a client proxy/stub, which
interacts the software on the client host that
provides the runtime support for the distributed
object system.
 The runtime support is responsible for the
interprocess communication needed to transmit the
call to the remote host, including the marshalling of
the argument data that needs to be transmitted to
the remote object.

04/15/24 15
 Distributed Object System - 3
 A similar architecture is required on the server side,
where the runtime support for the distributed object
system handles the receiving of messages and the
unmarshalling of data, and forwards the call to a
software component called the server proxy/skeleton.
 The server proxy interfaces with the distributed
object to invoke the method call locally (on the
remote host), passing in the unmarshalled data for the
arguments.
 The method call results in the performance of some
tasks on the server host.
 The outcome of the execution of the method, including
the marshalled data for the returned value, is
forwarded by the server proxy to the client proxy, via
the runtime support and network support on both
sides.
04/15/24 16
 Distributed Object Systems/Protocols
The distributed object paradigm has been widely adopted in
distributed applications, for which a large number of
mechanisms based on the paradigm are available. Among the
most well known of such mechanisms are:
 Java Remote Method Invocation (RMI),

 the Common Object Request Broker Architecture

(CORBA) systems,
 the Distributed Component Object Model (DCOM),

 mechanisms that support the Simple Object Access

Protocol (SOAP).
Of these, the most straightforward is the Java RMI

04/15/24 17
From Remote Procedure Call
to Remote Method Invocation

04/15/24 18
 Remote Procedure Calls (RPC)
 Remote Method Invocation (RMI) has its origin in a paradigm
called Remote Procedure Call (RPC)
 In the RPC model, a procedure call is made by one process to
another, with data passed as arguments.
 Upon receiving a call, the actions encoded in the procedure are
executed, the caller is notified of the completion of the call, and a
returned value, if any, is transmitted from the callee to the caller.
Pro ce s s A
Pro ce s s B

pro c1 (a rg 1 , a rg 2 )

retu rn v a l u e

a re m o te pro ce du re

04/15/24 e x e cu ti o n fl o w
19
 Local Procedure Call and Remote Procedure Call
h ost A

pro c1

e x e cu ti o n fl o w

pro c2

A l o ca l pro ce du re ca l l

h ost B
h ost A
1 . pro c1 o n h o s t A m a k e s a ca l l 4 . Th e p r o x y o n h o s t B
to pro c 2 o n h o s t B . pro c1 u n m a rs h a l l s th e da ta
pro c2
2 . Th e r u n t i m e s u p p o r t m a p s r e c e i ve d a n d i s s u e s a
th e ca l l to a ca l l to th e pro x y ca l l to pro c2 .
on h ost A. 5 . Th e c o d e i n p r o c 2 i s
3 . Th e p r o x y m a r s h a l l s t h e d a t a e x e cu te d a n d re tu rn s
a n d m a k e s a n IP C c a l l t o a to th e pro x y o n h o s t B .
pro x y o n h o s t B . 6 . Th e p r o x y m a r s h a l l s
t h e r e t u r n va l u e a n d
7 . Th e p r o x y r e c e i ve d t h e r e t u r n m a k e s a n IP C c a l l t o
va l u e , u n m a r s h a l l s t h e d a t a , pro x y th e pro x y o n h o s t A .
pro x y
a n d f o r w a r d s t h e r e t u r n va l u e
to pro c1 , w h i ch re s u m e s i ts
e x e cu ti o n fl o w .

A re m o te pro ce du re ca l l
(th e re tu rn e x e cu ti o n pa th i s n o t s h o w n )
04/15/24 20
 Remote Procedure Calls (RPC) - 2
 Since its introduction in the early 1980s, the Remote Procedure
Call model has been widely in use in network applications.
 There are two prevalent APIs for this paradigm.
 the Open Network Computing (ONC) Remote Procedure Call, evolved
from the RPC API originated from Sun Microsystems in the early 1980s.

 The other well-known API is the Open Group Distributed Computing

Environment (DCE) RPC.
 Both APIs provide a tool, rpcgen, for transforming remote
procedure calls to local procedure calls to the stub.

04/15/24 21
Java Remote Method Invocation

04/15/24 22
 Remote Method Invocation
 Remote Method Invocation (RMI) is an object-oriented
implementation of the Remote Procedure Call (RPC) model.
It is an API for Java programs only.
 Using RMI, an object server exports a remote object and
registers it with a directory service (e.g., RMI registry). The
object provides remote methods, which can be invoked in
client programs.
 Syntactically:
 A remote object is declared with a remote interface, a Java interface.
 The remote interface is implemented by the object server.
 An object client accesses the object by invoking the remote methods
associated with the objects using syntax provided for remote method
invocations.

04/15/24 23
 The Java RMI Architecture
D ire ctory se rvice

obje ct obje ct
clie n t se rve r
supports the interfac e w ith
the applic ation program

m aps the platform -independent s tub/skeleton stu b sk e le ton

layer to the platform -dependent transport
layer; c arries out rem ote referenc e protoc ols re m ote re fe re n ce laye r re m ote re fe re n ce laye r
tran sport laye r tran sport laye r
sets up, m aintains, and s huts dow n
c onnec tions; and c arries out the
transport protoc ol

logical data path

04/15/24 ph ysical data path 24

 Object Registry
 The RMI API allows a number of directory services to be used[1]
for registering a distributed object.
 We will use a simple directory service called the RMI registry,
rmiregistry, which is provided with the Java Software Development
Kit (SDK)[2].
 The RMI Registry is a service whose server, when active, runs on
the object server’s host machine, by convention and by default on
the TCP port 1099.

[1] One such service is the Java Naming and Directory Interface (JNDI), which is more
general than the RMI registry, in the sense that it can be used by applications that do not
use the RMI API.
[2] The Java SDK is what you download to your machine to obtain the use of the Java class
libraries and tools such as the java compiler javac .

04/15/24 25
 The interaction between the stub and the skeleton

A time-event diagram describing the interaction

between the stub and the skeleton:

stu b s k e le t o n R e m ote
Me th od
t im e
m a rs h a l pa ra m e t e rs ;
s e n d R e qu e s t
u n m a rs h a l pa ra m e t e rs
In vok e m e th od
e x e cu t e co de
a n d re t u rn a
v a lu e
re ce iv e re t u rn v a lu e
m a rs h a l re ply
s e n d re ply
u n m a rs h a ll re ply ;
re t u rn v a lu e
( ba s e d o n h t t p: //ja v a . s u n . co m . m a rk e t in g /co lla t e ra l/ja v a rim . h t m l)
04/15/24 26
 The API for the Java RMI
 The Remote Interface
 The Server-side Software
 The Remote Interface Implementation
 Stub and Skeleton Generations
 The Object Server
 The Client-side Software

04/15/24 27
 Stub and Skeleton
 RMI uses stub and skeleton object for
communication with the remote object.
 A remote object is an object whose method can
be invoked from another JVM. Let's understand
the stub and skeleton objects:

04/15/24 28
 Stub
 The stub is an object, acts as a gateway for the client side. All
the outgoing requests are routed through it. It resides at the
client side and represents the remote object. When the caller
invokes method on the stub object, it does the following tasks:
1. It initiates a connection with remote Virtual Machine (JVM),
2. It writes and transmits (marshals) the parameters to the remote
Virtual Machine (JVM),
3. It waits for the result
4. It reads (unmarshals) the return value or exception, and
5. It finally, returns the value to the caller.


04/15/24 29
 Skeleton
 The skeleton is an object, acts as a gateway for the
server side object. All the incoming requests are routed
through it. When the skeleton receives the incoming
request, it does the following tasks:
1. It reads the parameter for the remote method
2. It invokes the method on the actual remote object, and
3. It writes and transmits (marshals) the result to the
caller.

04/15/24 30
Stub and Skeleton

04/15/24 31
 Requirements of a Distributed application

 The application need to locate the remote

method
 It need to provide the communication with the
remote objects, and
 The application need to load the class
definitions for the objects.
 The RMI application have all these features, so
it is called the distributed application.

04/15/24 32
 RMI Steps
 Create the remote interface
 Provide the implementation of the remote
interface
 Compile the implementation class and create
the stub and skeleton objects using the rmic tool
 Start the registry service by rmiregistry tool
 Create and start the remote application
 Create and start the client application

04/15/24 33
Example

04/15/24 34
 1) create the remote interface
 For creating the remote interface, extend the Remote
interface and declare the RemoteException with all the
methods of the remote interface. Here, we are creating
a remote interface that extends the Remote interface.
There is only one method named add() and it declares
RemoteException.
import java.rmi.*;
public interface Adder extends Remote{
public int add(int x,int y)throws RemoteException;
}

04/15/24 35
 Provide the implementation of the remote
interface

 For providing the implementation of the

Remote interface, we need to extend the
UnicastRemoteObject class
import java.rmi.*;
import java.rmi.server.*;
public class AdderRemote extends UnicastRemoteObject implements Adder{
AdderRemote()throws RemoteException{
super();
}
public int add(int x,int y){return x+y;}
}

04/15/24 36
 Create the stub and skeleton objects using the
rmic tool.

 Next step is to create stub and skeleton objects

using the rmi compiler. The rmic tool invokes
the RMI compiler and creates stub and skeleton
objects.

 rmic AdderRemote

04/15/24 37
 Start the registry service by the rmiregistry
tool
 Now start the registry service by using the
rmiregistry tool. If you don't specify the port
number, it uses a default port number. In this
example, we are using the port number 5000.

 rmiregistry 5000

04/15/24 38
 Create and run the server application – Naming Class
public static java.rmi.Remote lookup(java.lang.String) throws It returns the reference of the remote object.
java.rmi.NotBoundException,
java.net.MalformedURLException, java.rmi.RemoteException;

public static void bind(java.lang.String, java.rmi.Remote) It binds the remote object with the given name.
throws java.rmi.AlreadyBoundException,
java.net.MalformedURLException, java.rmi.RemoteException;

public static void unbind(java.lang.String) throws It destroys the remote object which is bound with the given
java.rmi.RemoteException, java.rmi.NotBoundException, name.
java.net.MalformedURLException;

public static void rebind(java.lang.String, java.rmi.Remote) It binds the remote object to the new name.
throws java.rmi.RemoteException,
java.net.MalformedURLException;

public static java.lang.String[] list(java.lang.String) throws It returns an array of the names of the remote objects bound in
java.rmi.RemoteException, java.net.MalformedURLException; the registry.

04/15/24 39
 Create and run the server application

import java.rmi.*;
import java.rmi.registry.*;
public class MyServer{
public static void main(String args[]){
try{
Adder stub=new AdderRemote();
Naming.rebind("rmi://localhost:5000/sonoo",stub);
}catch(Exception e){System.out.println(e);}
}
}


04/15/24 40
 Create and Run the Client Application

 At the client we are getting the stub object by

the lookup() method of the Naming class and
invoking the method on this object.
 In this example, we are running the server and
client applications, in the same machine so we
are using localhost.
 If you want to access the remote object from
another machine, change the localhost to the
host name (or IP address) where the remote
object is located.
04/15/24 41
 Create and Run the Client Application
 import java.rmi.*;
 public class MyClient{
 public static void main(String args[]){
 try{
 Adder stub=(Adder)Naming.lookup("rmi://localhost:5000/
sonoo");
 System.out.println(stub.add(34,4));
 }catch(Exception e){}
 }
 }

04/15/24 42
 Comparison of the RMI and the socket APIs

The remote method invocation API is an efficient tool

for building network applications. It can be used in
lieu of the socket API in a network application. Some
of the tradeoffs between the RMI API and the socket
API are as follows:
 The socket API is closely related to the operating system,
and hence has less execution overhead. RMI requires
additional software support including proxies and directory
service which incur run time overhead. For applications
which require high performance, this may be a
consideration.

04/15/24 43
 Comparison of the RMI and the socket APIs

 The RMI API provides the abstraction which eases the

task of software development. Programs developed
with a higher level of abstraction are more
comprehensible and hence easier to debug.

 Socket API operates at a lower layer, it is typically

platform and language independent.
 Java RMI requires Java specific run time support,
An application implemented using Java RMI must
be written in java and can only run on java
platforms.
04/15/24 44
 RMISecurityManager
 To encounter the treats posed by a downloaded stub, Java provides a
RMISecurityManager class.
 An RMI program may instantiate an object of this class.
 Once instantiated, the object oversees all security-sensitive actions that arise
during the execution of the program.
 These actions include the accessing of local files and the making of network
connections, since such actions may result in undesirable modification of
local resources or misuse of network resources.
 In particular, the RMI run-time support requires that a server process install
a security manager before it can export any object that requires stub
downloading, and that a client process install a security manager before it
can download a stub.

04/15/24 45
 RMI Security Manager
 The RMISecurityManager enforces the security policy for classes that are
loaded as stubs for remote objects, by overriding all of the relevant access-
check methods from the SecurityManager.
 By default, stub objects are only allowed to perform class definition and
class access operations.
 java.lang.Object
 java.lang.SecurityManager
 java.rmi.RMISecurityManager
 Syntax:

 public class RMISecurityManager

 extends SecurityManager

04/15/24 46
 How to incorporate the Security Manager
class?
 To use a SecurityManager in your application, add the
following statement to your code
 Syntax:
 System.setSecurityManager(new SecurityManager());

 Implementation:

 if (System.getSecurityManager() == null)
 {
 // Setting the RMISecurityManager on System
 System.setSecurityManager(new SecurityManager());
 }

04/15/24 47
 Java.Policy file
 The java. policy file installed with the JDK
grants all permissions to standard extensions,
allows anyone to listen on un-privileged ports,
and allows any code to read certain "standard"
properties that are not security-sensitive, such
as the " os.name " and " file.

04/15/24 48
 Algorithms for Building an RMI application,
Allowing for Stub Downloading
 Algorithm for Developing the Server-Side Software
 Open a directory for all the files to be generated for this application.
 Specify the remote-server interface SomeInterface.java, and compile it to generate
the interface class file.
 Build the remote server class SomeImpl.java by implementing the interface, and
compile it using javac.
 Use rmic to process the server class to generate a stub.class file and a skelton.class
file: rmic SomeServer
 If stub downloading is desired, copy the stub file to an appropriate directory on the
HTTP host.
 Activate the RMIRegistry, if it has not already been activated.
 Set up a java.policy file.
 Activate the server, specifying (i) the codebase if stub downloading is desired, (ii) the
server host name, and (iii) the security policy file.

04/15/24 49
 Object Client-Side Algorithm for Developing the Client-Side
Software

1. Open a directory for all the files to be generated for this application.
2. Obtain a copy of the remote interface class file SomeInterface.class,
Alternatively, obtain a copy of the source file SomeInterface.java for
the remote interface, and compile it using javac to generate the
interface class file.
3. If stub downloading is not in effect, obtain a copy of the stub class file
and place it in the current directory.
4. Set up a java.policy file for application, and place it in an appropriate
directory or the current direct directory.
5. Activate the client, specifying (i) the server host name, and (ii) the
security policy file.

04/15/24 50
The HelloWorld Sample

04/15/24 51
Diagrams for the Hello application

H e llo I n t e rf a ce

U n i c a s t R e m o t e O bj e ct
s a y H e llo ( )

H e llo S e rv e r H e llo I m pl
H e llo C lie n t

lis t R e g is t ry ( )
s t a rt R e g is t ry ( )

U M L di ag r am

clie n t re g is t ry s e rv e r

re bin d( )
lo o k u p( )

s a y H e llo ( )

s e que nc e di ag r am
04/15/24 52
 Source files for the Hello application

 HelloInterface.java
 HelloImpl.java
 HelloClient.java

 Demo example:
 http://java.sun.com/j2se/1.4.2/docs/guide/rmi/
getstart.doc.html

04/15/24 53
 A Sample Enterprise Application
In the illustrated application, the object server provides remote methods
which allows the object clients to look up or update the data in an Expense
Records database. Programs which are clients of the object provide the
application or business logic for processing the data and the presentation
logic for the user interface which presents the data.

C lien t

C lien t RM I

RM I RM I C lien t
S er v er

J D BC
E x p en s e R e c o r d s

04/15/24 A n Ex pe n s e R e po rt in g S y s t e m , f r o m h ttp ://ja v a . s u n . c o m 54