Difference between revisions of "Protege Client Server RMI"

From Protege Wiki
Jump to: navigation, search
Line 23: Line 23:
  
 
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.
 
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.
 +
 +
[[Image:RMIProtocol02.png]]
 +
 +
 +
[[Image:RMIProtocol03.png]]
  
 
= Exporting RMI from a NAT'd server =
 
= Exporting RMI from a NAT'd server =
  
yyy
+
 
 +
[[Image:RMIProtocol04.png]]
 +
 
 +
[[Image:RMIProtocol-Router.png]]

Revision as of 08:35, February 23, 2009

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.

Tunneling RMI out of a private network

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.

RMIProtocol02.png


RMIProtocol03.png

Exporting RMI from a NAT'd server

RMIProtocol04.png

RMIProtocol-Router.png