Intro to RMI with Java

Get the WebProNews Newsletter:
[ Business]

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.

    DevArticles (http://www.devarticles.com) went “live-to-air” in November of 2001. Starting out as just a one man show ran by me from my bedroom, DevArticles quickly became one of the most popular developer sites on the ‘net. Most people attribute it to the way that we write our articles, but I’d also like to think that it’s our strong sense of community that has helped make us what we are today.

    Intro to RMI with Java
    Comments Off
    About DevArticles
    DevArticles (http://www.devarticles.com) went "live-to-air" in November of 2001. Starting out as just a one man show ran by me from my bedroom, DevArticles quickly became one of the most popular developer sites on the 'net. Most people attribute it to the way that we write our articles, but I'd also like to think that it's our strong sense of community that has helped make us what we are today. WebProNews Writer
    Top Rated White Papers and Resources

    Comments are closed.