Atom Feed SITE FEED   ADD TO GOOGLE READER

Java RMI without a webserver

One of the four steps to setup Java RMI is "Making classes network accessible." Since I'm new to Java RMI, I found this requirement surprising. We have a client and a server. Of the two of them, surely one of the two has a full set of classes. Why require a third server to host the classes?

I suppose they were thinking that somewhere near the RMI server would be a big expensive heavyweight J2EE container, and that thing can serve the classes. But even if I have the J2EE server setup, this is still annoying - I still need to configure the webserver, and then keep it's jars synchronized with the ones my RMI server is using.

Instead, I decided to do the Simplest Thing That Could Possibly Work. I wrote a tiny HTTP Server (168 lines of code) and used it to publish all the classes in my local JVM. Now in my RMI code, I simply need this:
    String currentHostname = "jessesmac.publicobject.com";
new RmiClassServer(currentHostname).run();

The RMI server serves classes to anyone who's interested. I don't need to tell it which classpath to use - it uses the exact same classes that the local classloader uses, via Class.getResource.

Sound useful for your RMI application? You'll need RmiClassServer.java and MiniHttpServer.java, both of which are available under your choice of Mozilla 1.1 or LGPL license.

A final word of caution - this server exposes everything on your application's classpath. Unless your classes themselves are public, please don't put this server (or your RMI server!) on your public website.
Well.. I think you're confused!

If you need to comunicate via RMI from the client to the server, just make sure the proper classes are on the client and on the server, and the client and server nodes are able to comunicate. That's it.. why a webserver}???
Marcio - the app I'm building lets a single client schedule work on many servers. The servers are dumb - they know little more than how to accept a Runnable and run it on the client's behalf.

With remote classloading, I can deploy the client and servers independently. For example, I can change the client without redeploying the server.