Protege Client Server RMI

From Protege Wiki

Revision as of 08:51, February 23, 2009 by Tredmond (Talk | contribs)

Jump to: navigation, search

How Does RMI Work?

This page is part of the Protege client-server tutorial.

First a disclaimer. I am not an expert on the RMI protocol. The following is based on observations of how the RMI protocol behaves and debugging problems that can happen in ordinary practice. This behavior is further confirmed by the "black magic" tricks (running an rmi server through NAT and tunneling a connection to an rmi server) that we describe in this section. I enthusiastically encourage others to correct or improve these pages.

This page discusses the interaction of a server, rmi registry and a client. The simplest case is shown in the figure below.

RMIProtocol01.png

The steps in the protocol are:

  1. The server registers (Registry.bind) a remote object with the RMI registry giving it a name. Inside the remote object is the hostname of the server. It turns out that this hostname comes from the -Djava.rmi.server.hostname=... jvm parameter.
  2. The client goes to the RMI registry to get the remote object bound to a particular name.
  3. The client invokes the remote object and contacts the server.
Even just this bit of information can be helpful debugging problems. For example, occasionally - often due to a system misconfiguration, the line
 HOSTNAME_PARAM=-Djava.rmi.server.hostname=`hostname`

from the run_protege_server.sh script will provide the wrong information. In particular sometimes the hostname command simply returns localhost. This means that the remote object registered in the RMI registry and therefore the object given to the client will indicate that it can be found on localhost. This will not work unless the client is on the same host as the server.

Black Magic Trick #1: Tunneling RMI out of a private network

Note that this example is not as well motivated as the next one but it is a little less dangerous. If you do this technique then you should make sure that you understand the security implications. Also I only currently know how to set this up on unix machines (including osx). I am sure that this works on Windows but there is one step where I don't know the magic incantation.

Sometimes you will have permission to access a private network but will be temporarily working outside the private network. The simplest way to gain access to the servers on the private network is to use a VPN. The Cisco VPN seems to be very popular. But VPN's have disadvantages. They often come with policies that make work difficult and they are not always available. An alternative that is occasionally useful is to use a tool such as ssh to tunnel the connection from your machine to the private network.

If you have ssh access then it is not difficult to set up the tunnels. Suppose that the machine you are connecting to is called my.office.com and the Protege server listens on port 5200 and the rmi registry is listening on port 5300. A command like

     ssh -L 5300:localhost:5300 -L 5200:localhost:5200 my.office.com

will do the trick. Then when you connect in the Protege client, you specify the machine as localhost:5300. Protege will then tunnel straight to the RMI registry and the RMI registry successfully returns the server object to you. However, unless you do something more, this technique still won't succeed. What happens is shown in the figure below.

RMIProtocol02.png

The problem is that when the server registers the server object with the rmiregistry, the hostname specified in the server object is my.office.com. The client successfully connects to the registry through the tunnel but when it gets the server object it tries to access it through my.office.com:5200. We some how need to convince the client to use localhost:5200 instead of my.office.com:5200.

This is where the magic unix incantation comes in. As root, you can edit the /etc/hosts file and add a line

     127.0.0.1    my.office.com

What this does is to falsely convince the client that the address my.office.com refers to is located at 127.0.0.1. Now the client goes to 127.0.0.1 when accessing the server object and the behavior is as shown below.

RMIProtocol03.png

Success!

Exporting RMI from a NAT'd server

RMIProtocol04.png

RMIProtocol-Router.png
Personal tools