Chris Adamson's Blog

Jini Archives

Jeri topples Stalin

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.

Java sightings at MacHack 2003

The idea of the MacHack conference - 48 hours of talking and coding, with an emphasis on doing clever but useless things with code - seems like it would cater exclusively to platform-specific Mac coders. But instead, Java has been a big part of this conference.

Ken Arnold's delightful keynote started with principles of good design, both of end-user applications and of API's offered to other developers. It was somewhat revelatory to note that JButton about 450 methods available. In a re-imagining of this class he showed how you could expose only the kinds of methods most developers will use or care about (setting button text, enabling and disabling, etc.), while not baffling beginning developers with methods that only a LayoutManager would ever call.

Ken also talked about this approach as expressed in jini and its concept of exposing ever-changing java-based services on an ever-changing network.

I gave a session on QuickTime for Java, while java.net editor Daniel Steinberg offered up two sessions: one on tuning Java applications for a more Mac-like experience (with and without code changes, with or without a Mac), and a second on Jini vis-a-vis Rendezvous.

But the real fun is the hack contest, where attendees offer up clever or pointless (preferably both) code hacks. My offering was a screen grabber written in QuickTime for Java, which allowed me to get to the full-screen drawing surface. My code is awful; I have a completely pointless conversion from a QuickTime QDGraphics to an AWT Image and back... but efficient or elegant code is so not the the point at MacHack. Anyways, its one claim to usefulness - which is bad in the MacHack way of thinking - is that it can do screen grabs while playing a DVD, which Apple's Grab.app won't:

Apparently, despite the fact that every copy of Mac OS X comes with Java 1.3.1 (with 1.4.1 a software download that's offered to you immediately after the install), the idea of a Java hack was a curve-ball. Their form for keeping track of the language or API of submitted hacks didn't have "java", so I got filed under "other"

Presumably, so did Ken Arnold's moodring, an exceptionally clever Jini application. The idea of this app is that users join the group and express their mood on a range from "Ecstasy" to "Hell", colored as blue to red respectively. The mood of all participants is averaged for a "group mood". As members change their mood, the change is quickly reflected on all users' desktops:

James Duncan Davidson described the result in a weblog from earlier this morning - audience members were encouraged to grab the app and join the demo. Thanks to Jini discovery, about a dozen people joined the group with no configuration necessary - just click and go. In fact, the bottleneck wasn't Jini, but the number of connections available to Ken's machine to download the app.

Daniel says, and rightly so, that a user shouldn't know or care what language an application is written in, just what it does. Hopefully we'll see more Java-based MacHacking in the future.

This work is licensed under a Creative Commons License.