Do I need a web server for machine to machine Java RMI?

Question

I'm try to get two Java processes to talk together via RMI. In 2016. On Java 8.

I get the feeling that things have moved on, but I'm an old fashioned kinda guy and would like to stick with plain RMI. Most of the on line documentation is fairly dated. The rest falls between various changes in the RMI framework. We currently have on line:-

• The original stub /skeleton method via rmic

• Dynamically generated stubs post Java 4

• Changes to the codebase parameter in JDK 7 Update 21

• Mention of HTTP /FTP servers as in this tutorial

I have a client.class and a server.class, each on separate physical machines. I'm uncertain whether I need to run a stand alone HTTP server (such as Apache httpd) to serve up stub files for downloading by the client. This seems the point of the codebase parameter. This also seems redundant to me though as isn't that the point of dynamically generated stub files attributed to the RMI Registry program. Doesn't this also make a mockery of having an all Java solution if I have to run httpd? And what files would you serve up from the web home directory? Would it be a 2nd copy of server.class, not the one exported to the RMI Registry? It all seems a bit of a mess documentation-ally.

So is a web server required for machine to machine RMI?

Answer 1

You can use RMI without the codebase feature. It isn't compulsory.

It's there to provide access not just to the stub, but to any other server-side classes the client may not know about: for example, if a remote method is specified to return an interface or abstract class, the codebase feature can be used to deploy the actual implementation(s) of the return value. This allows the implementation classes to be updated without a massive client deployment headache. It should be looked on as a deployment solution, not as an integral part of RMI.

I'm an old fashioned kinda guy and would like to stick with plain RMI. Most of the on line documentation is fairly dated.

Nothing much has changed. Dynamic stubs in 1.5, a codebase tweak in 1.7, nothing else major since 1.2.

I'm uncertain whether I need to run a stand alone HTTP server (such as Apache httpd) to serve up stub files for downloading by the client.

You don't. See above.

This seems the point of the codebase parameter. This also seems redundant to me though as isn't that the point of dynamically generated stub files attributed to the RMI Registry program.

Only if you think the codebase feature is only for stubs, but it isn't: see above. You can even use it in the reverse direction, from client to server, for implementation classes of interfaces or abstract classes used as remote method parameters.

Doesn't this also make a mockery of having an all Java solution if I have to run httpd?

Nobody said you had to run HTTPD, or even an HTTP server. It could be FTP for example. It could be an HTTP server implemented in Java. Lots of possibilities. Or you can not use the feature at all.

And what files would you serve up from the web home directory? Would it be a 2nd copy of server.class

No. Why? The client doesn't need server.class.

not the one exported to the RMI Registry?

That's not server.class either, it's the stub.

It all seems a bit of a mess documentation-ally.

I do not agree. None of the speculation you've perpetrated above appears in the documentation.

So is a web server required for machine to machine RMI?

No.

Answer 2

So is a web server required for machine to machine RMI?

NO. You don't specifically need a web server. It's just that the server machine(machine having Remote interface implemented with the help of Remote objects) should be visible(discoverable) from the client machine(machine calling method).

I have built several client-server applications and a distributed computing application as well, in which the only thing was to make basically the callee to be discoverable by caller. Like in case of application running in a local network, just configuring the /etc/hosts file did the work for me.

I have a client.class and a server.class, each on separate physical machines. I'm uncertain whether I need to run a stand alone HTTP server (such as Apache httpd) to serve up stub files for downloading by the client.

NO. Description is already given above.

Doesn't this also make a mockery of having an all Java solution if I have to run httpd? And what files would you serve up from the web home directory? Would it be a 2nd copy of server.class, not the one exported to the RMI Registry?

You don't need to have any web directory for a simple client-server application(simple non-web application) running in a network.

A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object. In the remote JVM, each remote object may have a corresponding skeleton (in Java 2 platform-only environments, skeletons are not required). The skeleton is responsible for dispatching the call to the actual remote object implementation. Read this link for details on Java RMI architecture.

No extra file needs to be downloaded to achieve this.