 |

News
Headlines
|
 |

by Neville Mehta
Page 1: Introduction
RMI is the acronym for Remote Method Invocation. As the
name suggests, it helps you locate and execute methods
of remote objects. It's like placing a class on Machine
A and calling methods of that class from Machine B as
though they were from the same machine. Confused? Well
if you are new to the concepts of enterprise programming
then it would take you some time to get this concept.
Rest assured however, as I have written this article to
ease you into the methodologies and concepts behind RMI.
This article will give you more than the facts on RMI.
What I mean by this is that after you finish reading this
article you will have an actual working demo of RMI on
your machine.
I can tell you from my personal experience that although
RMI isn't the only enterprise level solution for accessing
objects remotely, it is the easiest solution to implement.
RMI is a pure Java solution unlike CORBA where we can
have objects from different programming languages interacting.
In RMI everything you code will be in JAVA.
Before reading this article I will assume that you know
your JAVA basics quite well. You could continue to read
on to learn more about RMI, however knowing JAVA would
be an added advantage as this article focuses heavily
on JAVA coding examples to explain RMI.
Page 2: The Concept
As I mentioned earlier, RMI is a mechanism through which
we can call remote methods as though they were residing
on your own machine. This whole process will look transparent
to the end user: if I showed you a live demo and didn't
tell you it was RMI, then you wouldn't have even realized
the method is actually being called from a different machine.
Of course, a Java Virtual Machine must be present on both
the machines.
Objects which have to be made available to other machines
have to be exported to something called a Remote Registry
Server so that they can be invoked. So if Machine A wants
to call methods of some object on Machine B, then Machine
B would have to export that object on its Remote Registry
Server. Remote Registry Server is a service that runs
on the server and helps clients search and access objects
on the server remotely. Now, if an object has to be capable
of being exported then it must implement the Remote Interface
present in the RMI package. For example, say that you
want an object Xyz on machine A to be available for remote
method invocation, then it must implement the Remote interface.
RMI uses something called a stub and a skeleton. The stub
is present on the client side, and the skeleton the server
side. When you call remote methods, you don't just go
directly to other machine and say "hey, here's the method
name, here are the parameters, just give me back what
has to be returned and I am out of here".
There are a number of events that have to take place beforehand
which help in the communication of the data. The stub
is like a local object on the client side, which acts
like a proxy of the object on the server side. It provides
the methods to the client which can be invoked on the
server. The Stub then sends the method call to the Skeleton,
which is present on the server side. The Skeleton then
implements the method on the server side.
The Stub and the Skeleton communicate with each other
through something called a Remote Reference Layer. This
layer gives the stub and skeleton the capability to send
data using the TCP/IP protocol. Let's take a quick look
at a simple technique called "Binding".
Whenever a client wants to make a reference to any object
on the server, have you thought how he would tell the
server what object he wants to create? Well, this is where
this concept of "Binding" comes in. On the server end
we associate a string variable with an object (we have
methods to do this. We will learn more about these when
we start coding). The client tells the server what object
he wants to create by passing that string to the server,
thus letting the server know exactly what object you are
talking about. All of these strings and objects are stored
in the Remote Registry Server on the server.
Page 3: What Do We Have
To Code?
Now, before we jump into the code, let me tell you exactly
what we have to code:
* The Remote Object: This interface (yes our remote object
is actually an interface) will have only method declarations.
Hopefully you know that interfaces don't always have to
have method bodies, just declarations. The Remote Object
will have a declaration for each method that you want
to export. This remote object would implement the Remote
interface, which is present in the Java.rmi package.
* The Remote Object Implementation: This is a class that
implements the Remote Object. If you implement the Remote
Object, it's common sense that you would override all
of the methods in that object, so the remote object implementation
class would actually have all of the method bodies of
the methods that we want to export. This method will be
extended from the UnicastRemoteObject class.
* The Remote Server: This is a class that will act like
a server to the client wanting to access remote methods.
Here's the place where you will bind any string with the
object you want to export. The binding process will be
taken care of in this class.
* The Remote Client: This is a class that will help you
access the remote method. This is the end user, the client.
You will call the remote method from this class. You will
use methods to search and invoke that remote method. Ok
enough of the theory for now. Let's jump into the fun
part: the coding...
The Coding
We will start by coding the remote object. Save this code
as AddServer.Java in your favorite text editor:
import Java.rmi.*;
public interface AddServer extends Remote
{
public int AddNumbers(int firstnumber,int secondnumber)
throws RemoteException;
}
Let's have a look at this code. First of all we import
the rmi package to use its contents. We then create an
interface that extends the remote interface present in
the Java.rmi package. All remote objects must extend the
remote interface. We call this remote object AddServer.
We have a method called AddNumbers in this remote object,
which could be called by a client. We must remember that
all remote methods need to throw the RemoteException,
which is called whenever some error occurs.
Neville is currently studying in the Jai Hind College
for his bachelors degree in Commerce. He is 19 years old.
neville2150895@hotmail.com
Article courtesy of Mitchell Harper, who runs http://www.devarticles.com:
After FREE programming eBooks? Want to learn XML, Java,
Visual Basic, HTML, or how to promote your site for free?
Our collection of free eBook downloads might be just the
thing you need. Ready to download? Visit http://www.devarticles.com/ebooks.php
now!
|
|
 |