Transcript Distributed Objects

Distributed Objects
Message Passing
Vs
Distributed Objects
Message Passing

The message-passing paradigm is a
natural model for distributed computing
in the sense that it mimics interhuman
communications.
Message Passing

It is an appropriate paradigm for
network services where processes
interact with each other through the
exchange of messages.
Message Passing

The abstraction provided by this
paradigm may not meet the needs of
some complex network applications for
the following reasons:
Message Passing


Basic message passing requires that
the participating processes be tightly
coupled.
Throughout their interaction, the
processes must be in direct
communication with each other.
Message Passing


If the communication is lost between
the processes the collaboration fails.
Example:


Consider a session of the Echo protocol
If the communication between the client and the
server is disrupted, the session cannot continue.
Message Passing


The message-passing paradigm is
data-oriented.
Each message contains data
marshaled in a mutually agreed upon
format, and each message is
interpreted as a request or response
according to the protocol.
Message Passing

Example: Echo Protocol

The receiving of a message from a
process p elicits in the Echo server this
action: a message containing the same
data is sent to p.
Message Passing


The data orientation of the paradigm is
appropriate for network services and
simple network applications
It is inadequate for complex
applications involving large mix of
requests and responses.
Distributed Object

The distributed object paradigm is a
paradigm that provides abstractions
beyond those of the message-passing
model.
Distributed Objects

The paradigm is based on objects that
exists in a distributed system.

In Object-oriented programming
objects are used to represent an entity
that is significant to an application.
Distributed Objects

Each Object encapsulates


State
Operations
Distributed Objects

Example

Consider the objects of the
DatagramMessage class as shown
Import java.net.*;
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;
}
Distributed Objects

Each object instantiated from this class
contains three state and three
operations.
Distributed Objects

Local objects are objects whose
methods can only be invoked by a
local process.

A process that runs on the same
computer on which the object exists
Distributed Objects

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.
Distributed Objects


In a distributed object paradigm,
network resources are represented by
distributed objects.
To request service from a network
resources, a process invokes one of its
operations or methods, passing data
as parameters to the method.
Distributed Objects

The method is executed on the remote
host, and the response is sent back to
the requesting process as a return
value.
Distributed Objects

Compared to the message-passing
paradigm, the distributed objects
paradigm is action-oriented.

The focus is on the invocation of the
operations, while the data passed
takes on a secondary role.
Distributed Objects
An Archetypal Distributed
Object Architecture

Archetypal

Original Model
ADOA
The task of a distributed object system is
 to minimize the programming
differences between remote method
invocations and local invocations,
 Allowing remote methods to be
invoked in an application using syntax
similar to local method invocations.
ADOA

In reality, there are differences
because remote method invocations
involve communication between
independent process.
ADOA

The issues such as data marshalling
and event synchornization need to
be addressed.
An Archetypal
Distributed Object System
OBJECT REGISTRY
CLIENT
SERVER
An Archetypal
Distributed Object System
Object Registry
OBJECT CLIENT
OBJECT SERVER
CLIENT PROXY
SERVER PROXY
RUN-TIME SUPPORT
RUN-TIME SUPPORT
NETWORK SUPPORT
NETWORK SUPPORT
PHYSICAL DATA PATH
LOGICAL DATA PATH
ADOA

A distributed object is provided or
exported by a process, here called
object server

A distributed object is registered in the
object registry
ADOA

A distributed object is accessed by the
client process using object client


The object client looks up the registry for
a reference to the object.
This reference is used by the object client
to make calls to the methods of remote
object
ADOA


Logically the object client makes a call
directly to a remote method of object server.
Physically the client is handled by a
software components called



Client proxy - Object on behalf of client
Run time support - data marshalling
Network support – data transmission
Distributed Object Systems

The distributed object paradigm has
been widely adopted in distributed
applications, among the most well
known of such toolkits are:




RMI
CORBA
DCOM
SOAP
Remote Procedure Calls

Remote Method Invocation (RMI) has
its origin in a paradigm called Remote
Procedure Call.

Procedural Programming predates
object-oriented programming.
Remote Procedure Calls

Remote Procedure call model, a
procedure call or a function call is
made by one process to another,
possibly residing in a remote system,
with data passed as arguments.
Remote method Invocation

Remote Method Invocation(RMI) is an
object-oriented implementation of
Remote Procedure Call model.

It is an API for java programs only.
Remoted Method Invocation

An object server exports a remote
object and registers it with a directory
service.

The object provides remote methods,
which can be invoked in client
programs.
Remote Method Invocation



A remote object is declared with a
remote interface (in java).
The remote interface is implemented
by the object server.
An object client accesses the object by
invoking its methods.
Java RMI Architecture

Client-Side Architecture




Stub Layer
Remote Reference Layer
Transport Layer
Server-Side Architecture



Skeleton Layer
Remote Reference Layer
Transport Layer
Client Side Architecture

Stub Layer: A client process’s remote
method invocation is directed to a
proxy object, known as a stub.
Client Side Architecture

Remote Reference Layer: Interprets
and manages references made from
clients to remote service objects and
issues the IPC operations to next
layer.
Client Side Architecture

Transport Layer: It is TCP based and
therefore connection-oriented.

This layer and the rest of the network
architecture carry out the IPC.
Server-Side Architecture

Skeleton Layer: It lies just below the
application layer and serves to interact
with the stub layer on the client side.
Server-Side Architecture

Remote Reference Layer:
This layer manages and transforms
the remote reference originating from
the client to local references that are
understandable by skeleton layer.
Server Side Architecture

Transport Layer:
This layer is a connection oriented
layer based on TCP in the TCP/IP
suite.
Object Registry


The RMI registry a simple directory
service, is provided with the JSDK.
When active it runs on TCP port 1099
by default.
RMI Architecture
Object Registry
OBJECT CLIENT
OBJECT SERVER
STUB
SKELETON
Remote reference Layer
Remote reference Layer
Transport Layer
Transport Layer
Physical path
Logical path
RMI Architecture

Logically, from the point of view the
software developer, the remote
method invocation issued in a client
program interact directly with the
remote objects in a server program
RMI Architecture

Physically, the remote method
invocation are transformed to calls to
the stub and skeleton at runtime,
resulting in data transmission across
the network.
RMI Stub and RMI Skeleton
CLIENT
STUB
SKELETON
REMOTE METHOD
Remote method call
Marshal reques
TIME
Unmarshal
request
Execute
Remote
Method
Marshal reply
Unmarshal reply
Example of RMI




Create a Remote Interface
Create a Remote Implementation of
Interface
Create a Server to access instance of
remote method(interface)
Create a Client to access a remote
method
RMI API

Remote Interface:

Normal java interface which extends
Remote class for coping up with RMI
Syntax.
Example:




Import java.io.*;
Public interface add extends Remote{
Public int addition(int,int);
}
Remote Method(interface)

Implementation of remote interface by
supplying the functionality of method
Example:






Import java.io.*;
Class myadd extends
UnicastRemoteObject implements
add{
Public additon(int x,int y){
Return (x+y);
}
}
Remote Server

Remote server binds the instance of
implementation object to remote
registry
Example:



Class myserver {
Public static void main(String args[])
{ myadd ma=new myadd();
Naming.bind(“myobj”,ma);
}
}
Client

Remote Client Looks up the rmi
registry for the object reference and
fetches the reference to access remote
method
example







Import java.rmi.*;
Class client{
Public class client{
Public static void main(String args[]){
ref=Naming.lookup(“myobj”)
}
}
Steps for Building an RMI


Algorithm for Developing the serverside software:
Algorithm for Developing the Clientside software
Algorithm Server-side

1. Open a directory for all the files to be
generated for this application

2. Specify the remote server interface in
someinterface.java and compile it.

3. Implement the interface in
someimpl.java and compile it.
Algorithm Server-side



4. Use the RMI compiler rmic to process
the implemntation class and generate the
stub and skeleton file for the remote
object
5.Create the object server program
someserver.java and compile it
6. Activate the object server

Java someserver
Algorithm for Client-side



1.
Open a directory for all the files to
be generated for this application
2.
Obtain a copy of the remote
interface class file
3.
Obtain a copy of the stub file for the
implementation of the interface
someimple_stub.class
Algorithm for Client-side


4.
Develop the client program
someclient.java and compile it to
generate the client class.
5.
Activate the client

Java someclient.
LOCATION OF FILES
CLIENT
OBJECT CLIENT DIRECTORY
SERVER
OBJECT SERVER DIRECTORY
Someinterface.class
Someinterface.class
Someserver.class
Someclient.class
Someimpl.class
Someimpl_stub.class
Someimpl_stub.class
TESTING AND DEBUGGING

1.
Build a template for a minimal RMI
program.




start with a remote interface containing single
method signature.
Its implementation using stub
A server program that exports the object
A client program with just enough code that
invokes the remote method.
TESTING AND DEBUGGING


Test the template programs on one host
until the remote method can be made
successfully.
2.
Add one signature at a time to the
interface. With each addition, modify the
client program to invoke the added
method.
TESTING AND DEBUGGING

3.
Fill in the definition of each remote
method, one at a time. Test and
thoroughly debug each newly added
method before proceeding with the next
one.
TESTING AND DEBUGGING

4.
After all remote methods have been
thoroughly tested, develop the client
application using an incremental
approach. With each increment test and
debug the programs.
TESTING AND DEBUGGING
5.
Distribute the programs on separate
machines. Test and debug
RMI API vs SOCKET API


Socket API works closely with the
operating system and hence has less
execution overhead.
RMI API requires additional software
support, including proxies and
directory service, which inevitably incur
run-time overhead.
RMI API vs SOCKET API


Socket API doesn’t provide abstraction
for developing the application and
hence difficult to debug
RMI API provides abstraction for
developing the application and hence
easy to debug
RMI API vs SOCKET API


SOCKET API is typically platform and
language independent.
RMI API is platform and language
dependent
Execution





Start Registry(start rmiregistry)
Compile all java files(javac *.java)
Generate Stub(rmic myimpl)
Invoke Server(java myserver)
Invoke Client(java myclient)