Transcript Remote Object Reference

RMI
remote method invocation
Traditional network programming
The client program sends data to the server in some
intermediary format and the server has to parse the data, and
prepare response data in the required format, and sends
response data. The client then parses the response data and
displays the data.
This is good but it requires involved parties to communicate
via some application-level protocol designing which can
involve lot of coding and could be error-prone.
Request data
Response data
Inter-object communication
Solution to this is Inter-object communication using RMI.
(Inter-object communication can also b done using CORBA
–discussed at the end of this topic.)
RMI allows communication between two java residing on
different JVMs. This allows client applications to call an
object method located on the server. The object on the server
is called remote object and the method is called remote
method. In others words,
1.A set of collaborating objects which can reside anywhere.
These objects will provide a some services.
2.Any object residing in any machine can create an object of
the above type and call a method on that object as if they
were residing on the same machine.
RMI
In RMI terminology, server is the one that hosts the remote
object (also called server object) and the client is the one
which is invoking the remote method. RMI technology
internally uses network programming to achieve this.
server
client
customer
warehouse.findProduct()
warehouse
product
RemoteObject
For RMI to be possible 3 things are required:
1. Client java object must have access to the server
java object.
a. Server needs to advertise its objects that can be
accessed remotely.
b. Clients need a unique way to locate the remote
objects.
2. The method parameter must be some how shipped
to the other machine.
3. The return data also must be shipped back in
some way.
Point 1: Registering remote object
How will the server announce the availability of this object to
other clients ?
The Sun RMI library has something called a bootstrap registry
service. This service is a naming and directory service where
servers can register its remote object and client can locate
remote objects. The registry service can be in the same
machine as the server machine or in the different machine.
1.First the server program registers server (remote) objects
with the bootstrap registry service. Server programs provides
a name for the object using which the client do the can lookup.
As a result of this a Remote Object Reference is created. The
reference to the object and a name is registered in the registry.
Remote Object Reference is associated with every remote
object. It represents unique identifier of remote object in the
distributed system.
Internet address of the server+port no+time of creation
+local object no.+ name of the remote object’s interface.
There is a table maintained by RMI architecture to map
actual objects and its remote object reference.
2.Now the client access the remote object by specifying the
name of the object along with the url. The protocol used is
‘rmi i.e. rmi://servername:port/objectname.Default port is
1099.
Client
Server
lookup()
bind()
Remote object Reference
Name
193.139.100.1+1099+555444+2222+Dict
English_Dict
…
..
bootstrap registry service.
Point 2: Stub
When the client access the remote object by specifying the
name of the object along with the url what is returned is
something called a stub.
A stub for a remote object acts as a client's local
representative or proxy for the remote object.
Therefore, client object attempts to makes a call on server
object (remote object), it actually calls a method on the stub
that resides on the client machine( stubs are dynamically
downloaded from the server m/c to the client m/c).
The stub has the same methods which remote object has. The
stub forwards the request via RMI framework to the remote
object.
Stub takes care of sending the data to the server object.
The process of converting data or object into a byte
stream by the stub is called parameter marshalling.
Stub does the following tasks
1.Initiates a connection with remote JVM.
2.Marshals the parameters and send to the remote JVM.
3.Waits for the reply from the remote objects.
4.Unmarshals the return value and returns to the client
program.
Point 3: Skeleton/Server side process
On the server side, the receiver object performs the following
actions for every method call:
1.It unmarshals the parameters. Parameters should be
serializable.
2.It locates the object to be called.
3.It calls the desired method
4.It gets the return data and marshals it.
5.It sends the marshaled data to the client.
In Java 1.x each remote object may have a corresponding
skeleton (from java 2 onwards, skeletons are not required).
server
client
Client
Stub
Skeleton
Server
Call stub method locally
Send the marshaled parameters
Call server method locally
Send the marshaled return value
return value
RMI uses a protocol called Java Remote Method
Protocol(JRMP).
Client
Server
Application layer
Stub
Skeleton
Presentation layer
Remote reference layer
Remote reference layer
TCP
TCP
IP
IP
Hardware interface
Hardware interface
RMI Architecture
Session layer
Transport layer
Network layer
Physical layer
The remote reference layer
• Defines and supports the invocation semantics of
RMI connection.This layer provides Java Remote
Method Protocol(JRMP).
• On the client side it maintains a table of remote
object reference and its stub objects.
• On the server side it maintains a table of remote
object reference and its local reference.
Lookup steps
When client invokes a lookup for a particular url in registry
1. A socket is opened to the specified port.
2. Since registry implementation on the server itself is remote
object, a stub to that remote object is returned from the
host. The stub acts as proxy for the registry.
3. The call to lookup is performed on this stub object and
another stub for the actual remote object is returned
4. Once this stub is obtained the further interaction takes
place with this stub.
Good news
Stub classes hence have lot of work to do. Good news
is that stub classes can be created automatically.
Since client requires stub classes, they are also
automatically downloaded by the client. –Dynamic
class loading.
So classes in the server can be changed anytime
without affecting client. When the client makes a call
to the remote object, the updated stub gets
automatically downloaded.
Implementation
1. Define a remote object interface which will contain
methods of the remote object that client can invoke. It
should extend ‘Remote’ which contains no methods.
2. Implement class for the remote object ( which will
implement the above remote object interface).
3. Generate stubs
4. Write client class which will invoke the remote object’s
methods.
5. Start the registry and register the object and run the server.
6. Run the client
1. Remote object interface
A remote interface is the set of methods that the client can invoke on
the remote object.
Rules:
•Must be a public class.
•Must extend java.rmi.Remote interface.
•All methods in this class should throw RemoteException.
•If the remote methods have any remote objects as parameters they
must be of interface types.
java.rmi.Remote interface has no methods. It is just used to tag an
object as remote object.
Only object of Remote type can be registered in bootstrap registry.
import java.rmi.*;
public interface Dict
extends Remote{
public String getMeaning(String word) throws
RemoteException;
}
Rules:
2. Remote object class
•Must be a public class.
•Must implement java.rmi.Remote interface.
•Must extends java.rmi.RemoteServer class which is an
abstract class that has some method for basic
communication between server and client objects.
java.rmi.server.UnicastRemoteObject is a convenience class
that implements extends Remote server class and provides
implementation for all the methods. So invariably all the
remote object extends this class.
•Create a remote object and bind a name to it so that the
name and the remote object could be registered in the
registry.
import java.rmi.*;
import java.rmi.server.*;
import java.util.Hashtable;
public class DictImpl extends
UnicastRemoteObject implements Dict{
Hashtable wordlist= new Hashtable();
public DictImpl() throws RemoteException{}
public String getMeaning(String word) throws
RemoteException{
return (String)wordlist.get(word);}
private void setWord(String word, String
meaning){
wordlist.put(word,meaning);
}
public static void main(String str[]){
try{
DictImpl dic= new DictImpl();
dic.setWord("Fantasy","Dream");
dic.setWord("Earnest","sincere, honest");
java.rmi.Naming.rebind("EnglishDic",dic);
}catch(Exception e){
System.out.println(e);
}}
}
3. Generate stubs
After creating remote object class, we need to create
stubs, so that client can download it. A tool called
rmic generates stubs automatically.
rmic –v1.2 DictImpl
Creates DictImpl_Stub.class
For JDK 1.1
rmic DictImpl
4. Write client class
1. Client program cannot download remote stubs from
network if security manager has not been set.The
RMISecurityManager is a security manager which should be
set to enable RMI.
System.setSecurityManager(new
RMISecurityManager())
2. Client program makes a lookup for remote object.
3. While running client client.policy file is specified so
that the RMISecurityManager that is loaded gets the policy
from this file.
public class DictClient {
public static void main(String str[]){
try{
System.setSecurityManager(new
java.rmi.RMISecurityManager());
String url="rmi://localhost/EnglishDic";
Dict dic =(Dict)java.rmi.Naming.lookup(url);
System.out.println(dic.getMeaning("Earnest"));
}catch(Exception e){
System.out.println(e.toString());
}
}}
client.policy
grant{
permission java.security.AllPermission;
};
Running the application
1. Compile all source files.
javac *.java
2. Run rmic on the implementation class
rmic –v1.2 DictImpl
3. Start RMI registry
start rmiregistry
4. Start the server
Start java DictImpl
5. Run the client
java –Djava.security.policy=client.policy DictClient
Server
Class which creates server object(Dict_Impl)
Client
1
Dict_Impl
Dict_Client
7
12
16
8
2
3
Dict_Impl_Stub
Dict_Impl_Skeleton
11
6
9
15
4
RRL maintains a table that
maps Dict_Impl reference
object and the stub objects.
10
RRL maintains a table of
Dict_Impl reference object
and its local reference
14
5
Registry maintains a mapping of Dict_Impl
reference object and its name
bootstrap registry service
13
CORBA
Common object request broker architecture.
Standard by OMG (Object Management Group) group.
Defines the common mechanism for interchanging data and
discovering services.
The object exchanging data may be objects written in any language.
The idea is that task of finding out the information about the object
that provide services and activating any requested services is
delegated to a so-called Object request broker(ORB). = Specification
followed by most ORB is called Inter-ORB protocol (IIOP).
Sun and IBM have developed next version of RMI that uses IIOP
called RMI-IIOP.
ORB