Jini has again been in the news a lot lately: The Tenth Jini Community Meeting took place last month in Brussels, and Sun's donation of the Jini codebase to the Apache Foundation has generated a lot of developer excitement as well.

The Java Posse interviewed long-time Jini hand Van Simmons about his current open-source project, ComputeCycles that uses Jini, together with GlassFish, for an on-demand compute grid.

When asked why Jini has not yet enjoyed much broader developer acceptance, Van Simmons pointed out that,

The barriers are that it's a hard problem [Jini] is trying to solve, and it's just not well-adapted to most of commercial uses of Java. For good or bad, the world is largely a Web 1.0 world right now, becoming more of a Web 2.0 kind of world. Jini probably has more of a place in the Web 2.0 setting...

[Today] most of the applications that are written are Web apps. If you really look at what Java is being used for, of those millions [of] Java programmers out there, what do most do day in and day out, I think they write Web apps. For some of the technical reason I [speak about in this interview], you can't even put Jini in a servlet engine.

Van Simmons noted, however, that the scale and types of problems people are working on are changing, making Jini more relevant to developers' problems:

Once you get beyond simple client-server kinds of things, and you're thinking in terms of... multiple services that aren't necessarily housed in the same JVM together, you need to look at Jini. Not [just] with an eye to using Jini, but with the eye to understanding these design patterns.

How do you discover what's available, how do you publish the fact that you're available for others to discover? A group of people has already thought through those issues.... just following their design patterns will be informative for you.

If you're working on something that's got to scale, for reliability reasons or availability reasons, to a number of processes that have to interoperate, then [Jini] is worth taking a look at. If you need to solve the problem of somehow giving an arbitrarily large number of machines the same bit of byte code, and do that in a secure manner, I don't know of anything else but Jini that can do that.

Developers new to Jini are often baffled by Jini's mobile code feature: Instead of focusing on a communication protocol, such as HTTP or SOAP, a Jini developer is free to focus on service interfaces, because the Jini infrastructure hides protocols behind chunks of bytecode that move from one JVM to another. Van Simmons told The Java Posse that such mobile code-based distributed computing is really an evolution of client-server design:

Ordinarily, in the RMI sense, I hand you a proxy, and all that code gives you is the ability to turn around and invoke my method remotely. If, on the other hand, I have the ability to download code into your JVM, I can wrap that dynamic proxy in what's called a smart proxy. That isolates you from the details of the communication protocols. You can view the [Jini] code downloading feature as a means of dynamically changing your communication protocol in a client-server context.

Suppose that what you want to do for performance reasons is to cache information on the client side, there are lot performance optimizations there, and that requires me to send you code that wraps my proxy. Jini does that.

To what extent is the architecture of your projects distributed beyond the traditional three-tier enterprise model? How do you ensure that all those distributed components and processes work reliably together? Have you tried Jini in your projects?