Remote Method Invocation
Remote Method Invocation
DISTRIBUTED OBJECTS
Remote Object - an object whose methods can be invoked from another Virtual
Machine.
Remote Interface - a Java interface that declares the methods of a remote object.
similarly the programmer of the server object doesnt want to fuss with the client
communication.The solution is to install a second proxy object on the server.The
server proxy communicates with the client proxy & it makes regular method calls
to the server objects.
a) RMI (Remote Method Invocation) It supports method calls b/w distributed java
objects.
In RMI, the object whose methods makes the remote call is called the client object.
The remote object is called the server object.The computer running the java code
that calls the remote method is the client for that call.
The computer hosting the object that processes the call is the server for that call.
Registration (binding)
A server can register its remote objects with a naming
service the rmiregistry.Once registered, each remote
object has a unique URL.
when client code invokes a remote method on a remote object, it actually calls an
ordinary method on a proxy object called a stub.The stub resides on the client
machine.The stub packages the parameters used in the remote method into a block of
bytes. This packaging uses a device independent encoding for each parameter.
The process of encoding the parameters is called parameter marshalling.The Purpose
of parameter marshalling is to convert the parameters into a format suitable for
transport from one m/c to another.
Skeleton
This process is complex, but it is completely automatic & to a large extent transparent to
the programmer.
For ex: consider a method with return type Product.The client program needs the class
file product.class to compile,but now suppose server constructs & return Book object &
Book is a subtype of Product.Client have no idea where to find the class file
Book.class. Therefore a class loader that will load required classes from the server is
required.RMI uses a special RMIClassLoader that loads at runtime the classes required
for remote invocations.whenever a program loads new code from another network
location,there is a security issue.For that reason,you need to use a security manager in
RMI client applications.This is a safety mechanism that protects the program from
viruses in stub code.For specialized applications,programmers can substitute their own
class loaders & security managers.
Skeleton
Stub Server
1. Server Creates
Client Virtual Remote Object
Machine Server Virtual Machine
2. Server Registers Remote Object
Client Remote
Object
1
Skeleton
Stub Server
RmiRegistry
RmiRegistry
6
Skeleton
Stub Server
import java.rmi.*;
public interface Hello extends Remote
{
public String sayHello() throws RemoteException;
}
import java.rmi.*;
import java.rmi.server.*;
public class HelloImpl extends UnicastRemoteObject
implements Hello
{
public HelloImpl() throws RemoteException
{
super();
}
public String sayHello() throws RemoteException
{
return "Hello! How r u? ";
}
}
3. Server Program
import java.rmi.*;
import java.rmi.server.*;
To access a remote object that exists on the server,the client needs a local stub
object.Then how can a client request such a stub? The most common method is to call
a remote method of another server object & get a stub object as a return value.
A server programs registers objects with the bootstrap registry service & the client
retrieves stubs to those objects.You register a server object by giving the bootstrap
registry service a reference to the object & a name.
RMI URLs start with rmi:// & are followed by a server, an optional port number,
another slash, & the name of the remote object. Eg:
rmi://localhost:99:port/central_warehouse
For security reasons,an application can bind,unbind or rebind registry object refrences
only if it runs on the same host as the registry.
Registry used for client bootstraping to get the initial reference.
java.rmi.Naming
a) registry access
b) URL format : prot://host:port/name
c) default protocol : rmi
d) default host : localhost
e) default port : 1099
f) all static methods:
void bind(String name, Remote obj);
void rebind(String name, Remote obj);
void unbind(String name); // unbinds the name
Remote lookup(String url); // returns a stub
When a remote object is passed from the server to the client, the client receives a
stub. Using the stub, it can manipulate the server object by invoking remote methods.
The object, however stays on the server. It is also possible to pass & return any
objects with a remote method call, not just those that implements the Remote
interface. The client gets a copy of the string. Then, after the call, the client has its
own string object to work with.
This means that there is no need for any further connection to any object on the server
to deal with that string.
Whenever an object that is not a remote object needs to be transported from one Java
virtual machine to another, the Java virtual machine makes a copy & sends the copy
across the network connection. This technique is very different from parameter
passing in a local method. When u pass objects into a local method or return them as
method results, only object references are passed. However, object references are
memory addresses of objects in the local java virtual machine. This information is
meaningless to a different java virtual machine. The RMI mechanism can also make
copies of more complex objects, provided they are serializable.RMI uses the
serialization mechanism to send objects across a network. This means that only the
information in any classes that implement the serializable.
Eg: An object of type customer is then sent to the server.
Because customer is not a remote object, a copy of the object is made on the server.
The server program sends back an array list of products. The array list contains those
products that match the customer profile & it always contains that one item namely, a
copy of the book core java. Again ArrayList is not a remote class, so the array list is
copied from the server back to its client.
In remote passing objects, the client receives a stub object, then saves it in an object
variable with the same type as the remote interface. The client can now access the
actual object on the server through the variable. The client can copy this variable in
its own local machine all those copies are simply references to the same stub. Only
remote interfaces can be accessed through the stub. A remote interface is any
interface extending Remote. All local methods are inaccessible through the stub. A
local method is any method that is not defined in a remote interface. Local methods
can run only on the virtual machine containing the actual object.
Stubs are generated only from classes that implement a remote interface & only the
methods specified in the interfaces are provided in the stub classes. If a subclass
doesnt implement a remote interface but a superclass does, & an object of the
subclass is passed to a remote method, only the superclass methods are accessible. A
remote class can implement multiple interfaces. For Eg:
Now when a book object is passed to a remote method, the recipient obtains a stub that
has access to the remote methods in both the Product & the StockUnit class.
Stubs do not have a clone method, so you cannot clone a remote object by invoking
clone on the stub. The reason is:
If clone were to make a remote call to tell the server to clone the implementation object,
then the clone method would need to throw a RemoteException.
We used a server program to instantiate & register objects so that the clients could
make remote calls on them. However in some cases, it may be wasteful to instantiate
lots of server objects & have them wait for connections, whether or not client objects
use them. The activation mechanism lets you delay the object construction so that a
server object is only constructed when atleast one client invokes a remote method on
it.
To take advantage of activation, the client code is completely unchanged. The client
simply requests a remote reference & make calls through it.
}
You must provide a constructor that takes two parameters:
a) An activation ID
b) A single object containing all construction information wrapped in a
MarshallObject.
When you place a serialized (or marshalled) copy of the construction information inside
the activation descriptor. Your server object constructor should use the get method of the
MarshalledObject class to deserialize the construction information.
The activation program exits after registerin & binding the activation receivers. The
server objects are constructed only when the first remote method call occurs.
7) CORBA
CORBA lets u make calls between objects written in any language. CORBA is an
industry standard for distributed object computing, developed by Object Management
Group (OMG).
RMI is Java-only.
RMI is not an industry standard (it is a product of Sun).
RMI does not provide such a rich set of services.
RMI is simpler to use and integrates smoothly with Java.
A CORBA Example
1) first you initialize the ORB.The ORB is a code library that knows how to talk
to other ORBs & how to marshal & unmarshal parameters.
org.omg.CORBA.Object
object=orb.resolve_initial_references(NameService);
NamingContext namingcontext=NamingContextHelper.narrow(object);
IDL syntax is :
interface Product {
string getDescription();
};
IDL compiler generates a number of other source files the stub class for
communicating with the ORB & three helper classes.
IDL compiler generates a class with suffix Holder for every interface. for ex: when a
Product interface is compiled, it automatically generates a ProductHolder class.
In IDL you can use sequence construct to define an arrays of variable size.u must
define a type before u can declare sequence parameters. Ex:
interface Warehouse {
ProductSeq find(Customer c);
};
SOAP is an XML protocol, like CORBAs IIOP ,that provides a protocol for
invoking remote methods.
In recent years, web services have emerged as a popular technology for remote
method calls.
WSDL:
WSDL is analogous to IDL.It describes the interface of the web service, the methods
that can be called & their parameter & return types.
The WSDL descriptor describes the services in a language independent manner.For
Ex: the WSDL for the Amazon web services (located at
http://soap.amazon.com/schemas3/AmazonWebServices.wsdl) describes an
AuthorSearchRequest operation.
The Amazon web service allows a programmer to interact with the Amazon system for a
wide variety of purposes.For ex: you can get listings of all books with a given author or
title, or you can fill shopping carts & place orders.Amazon makes this service available
for use by companies that want to sell items to their customers, using the Amazon
systems as a fulfillment backend.