Why do you need an HTTP server at all in RMI ?

[Remi Bastide]

There is something I cannot figure out quite right :

In general you need an HTTP server in RMI to get some java code moved
around.

If I understand correctly the typical scenario when you need this is :

- A client calls a method on a remote object that is declared to
return an instance of class A

- The server returns an instance of class B which is a subclass of A

- If B.class is not available at the client's site, then the client
needs to find it somewhere, and the codebase property is used there
(usually it points to an HTTP server)

My point is, if the client can call the server, then there is already
a connection between the two, and so while not use this connection to
download the code as well ? The same connection could be used to
transport the RMI calls and returns, and the missing classes if
needed.

Hope I made myself clear, I'm a bit confused...

 

[Gerbrand van Dieijen]

There is something I cannot figure out quite right :

In general you need an HTTP server in RMI to get some java code moved
around.

You don't need one in general.
Only if your server has an firewall or the client has an firewall and no
proxyserver, you could use a http server to tunnel data.

 

[Steve W. Jackson]

:There is something I cannot figure out quite right :
:
:In general you need an HTTP server in RMI to get some java code moved
:around.
:
:If I understand correctly the typical scenario when you need this is :
:
:- A client calls a method on a remote object that is declared to
:return an instance of class A
:
:- The server returns an instance of class B which is a subclass of A
:
:- If B.class is not available at the client's site, then the client
:needs to find it somewhere, and the codebase property is used there
usually it points to an HTTP server)
:
:My point is, if the client can call the server, then there is already
:a connection between the two, and so while not use this connection to
:download the code as well ? The same connection could be used to
:transport the RMI calls and returns, and the missing classes if
:needed.
:
:Hope I made myself clear, I'm a bit confused...

This is why RMI is more confusing than it needs to be, IMHO.

An earlier respondent says that you generally don't need one, and in my
usage that's entirely correct. But if you look carefully at many
examples, you'll see that "rmiregistry" is expected to be run with NO
classes visible in its classpath. It should not have a CLASSPATH
variable set and should be started such that no classes and/or jar files
are visible to it. This means that it will be unable to resolve any
references to any classes.

Remember that before calling any methods on your "server object", you
first have to retrieve a stub reference to it from the rmiregistry. So
when running rmiregistry without any classes visible to its classpath,
your client will not be able to obtain a remote object when needed
unless the rmiregistry application is able to obtain a stub of the
desired class. The application that bound the name to the object you're
after should have provided a codebase, and rmiregistry will attempt to
obtain the stub via HTTP.

I would guess that the existing connection isn't used because the
rmiregistry doesn't really maintain any connections to objects it binds.
Instead, it probably stores something that will be used when necessary
to obtain an actual stub when first requested. Of course, there are
policy issues when it comes to accessing files on the "server" object's
host and there's the fact that its application's own classpath could
include classes in a huge number of places all over its local system.
But I can't say with any certainty just why such an approach was used.

So my usage has taken a much simpler approach, which is to simply make
the same jar file available to my client and server applications, and to
rmiregistry as well. It eliminates any concerns about access policies
or the need for an HTTP server. All parties involved have access to the
interfaces, stubs, etc., when needed. The downside is that all parties,
including the rmiregistry, must know in advance that such item
references could be needed. But in my setting, that's definitely the
case, so the simplification I gain is well worth it.

= Steve =