Posted by editor
on July 1, 2004 at 9:53 AM PDT
Jini now has an answer for running on Stalinist networks.
At a previous job, we developed a Jini-based system to discover and expose whichever of our services were present on a customer's network. This led to a large Jini federation within the company's network, which led to problems as we hopped firewalls to remote points on the WAN.
Complicating the matter was the network admins' all-too-typical Stalinist network policies, preferring to lock down every port except for 80, with maybe a few known ports exposed if they could be held to an absolute minimum. This is deadly for most RMI applications, which prefer to communicate over whatever sockets appear to be available.
I asked about this in a Jini session on Tuesday, and was told the answer was coming Wednesday.
Sure enough, session TS-1054 covered Extending RMI with Firewall Traversal and Serialization Caching , with a solution to my problems.
The solution is Jini's new Jini Extensible Remote Interface , aka Jini ERI, or just "Jeri". This new approach to RMI allows for pluggable implementations, allowing you to run your remote calls over old-RMI-type socketry, http, https, even JXTA and in-memory RMI.
So how does Jeri get past Stalin? The solution is to put a remote box outside the firewall or in a DMZ. This "relay" box listens on known ports for the server (inside the firewall) to connect to it. Once connected, the relay can use that connection to the server. The clients see the relay as the service — whether it's the relay box or server box is irrelevant — so they can participate in discovery and remote method calling as normal. Perhaps more importantly, use of an outside box (presumably it could be the box hosting the relay) allows the client to download classes that Jini tells it are needed. This completes the pieces we need for Jini - discovery, dynamic downloading of needed code, and remote method invocation.
And all it costs to keep Stalin from purging our app is a cheep box in the DMZ.