If recent events are an indication, the Jini dream is enjoying a renaissance. On the heels of the Jini community meeting last month came an announcement from the Canadian company Psinaptic of a new Jini-based product, JCopia.

While most distributed systems, including Web services, focus on communication protocols, Psinaptic's solution of bringing non-Java devices into Java networks relies on Java byte-code instead as a communication protocol. Cameron Roe, Psinpatic's chief software architect, summarized this difference in a telephone interview with Artima:

We looked at [many] distributed systems and algorithms, and found that they fell in either of two categories. The first category translates distributed computing into data that usually takes the form of XML. From that came things like SOAP and Web services, where you translate method calls to XML, and you pass your method call parameters across the network, and that's translated on the other side, and then mapped to a method call on that other system.

Then we learned about Jini, and found [that] it did not do that translation, it did not use XML. Instead, it moved the code from JVM to JVM. We thought that was a much more powerful model than the remote procedure call model, including the RMI model, which Sun used before for their RPC system.

The concept of moving code around was a powerful paradigm, [but] the problem was that Jini was just too big... when all was said and done, running [Jini] took up between 10 and 12 [MB] of memory. We took the Jini specifications and re-wrote the Jini lookup service, and got it down to about a 100 Kb JAR file...

Following [that], we determined that we didn’t even need Java in order to have a lookup service... We then re-wrote the lookup service in C so that it would run on even smaller devices than the 100K Java JAR file would. Now you can have devices, sensors, actuators, very small embedded processors that can participate in a Jini distributed computing federation.

Roe then highlighted the benefits of running Jini lookup services on devices without a resident JVM:

Think of the thermostat in your house—it's a pretty dumb device. If you want to have your thermostat to participate in a smarter house where it would interact with your [home automation] system to try to manage power in the house—for instance, running the air conditioning only during certain times of the day, or it being able to respond to messages from the power grid, such as to slow down during peak hours—a dumb thermostat is not going to be able to do that.

While it's easy to make a smart thermostat, it's very hard for the industry to decide what the application should be on that thermostat. How is it going to respond? Is it going to use Web services, WSDL, RMI, CORBA, or its own proprietary messaging protocol?

Our vision is that that thermostat comes with a [Jini] lookup service, and that lookup service will have in it the Java bytecodes that will tell any JVM [on the network] how to interact with that thermostat...

That way you don't have to install in your home different applications to interact with thermostats from different manufacturers. Your smart home will look for services, and when it finds them, it downloads those services [by retrieving the byte codes from those non-Java devices], and those services know how to interact with the thermostat. [In that world], each device is self-contained and autonomous. It comes with the service to use and to interact with.

While Roe's product enables a non-Java device to hand out Java byte code on the network, the system still requires that clients of that device know in advance the semantics of the device's Java interface. We asked Roe how agreement on interfaces is tackled in a Jini smart home:

The interface problem is the same for everybody. Whether you're using a closed, proprietary messaging system or API, or even Web services, you still have to decide on the API. That's not a problem unique to Jini, or even to the computing world... The good news is that the only prior knowledge [clients] have to have is the interface. Clients don't need to know anything about the implementation details.

In Psinaptic's most recent product, JCopia, Roe applied the bytecode-as-protocol approach to the problem of keeping TV set-top boxes updated:

Once a set-top box is set up in a home, how do you keep that set-top box updated with the latest and greatest operating systems and services? There are now two ways of doing that. One is a proprietary method of updating your device. Everyone is familiar with that. Norton [AntiVirus] uses that to update their antiviral product, and Microsoft has their XP update to check a Web site and to download a new install script, which then installs the software on the system. PlayStation 2 follows a similar idea.

A second way of doing that is to use something like OSGi, where you have a backbone or a framework where you can install JARs, and have those JARs make the connections with other JARs [on the device].

The problem with those systems is that they are what you call a push system, where the service provider, the cable company, is going to push applications or JARs to your set-top box, just as Microsoft pushes updates to your PC.

JCopia uses the Jini framework to hunt on specific Web sites to see if there are any update services that are available for a device... When you have a set-top box, you are usually locked into one provider. With this system, you can use a set-top with multiple providers. As Jini is looking for services, a second [cable] provider would simple offer you, say, a World Cup service that your main provider does not have. You don't need to change providers, you just want to use that one-off service from the second provider. As long as there is a way for a set-top box find services, you can use that service.

Not only can you update your set-top box or device, but the service provider can also offer short-lived services. For instance, if you don't have an HBO subscription and just want to watch to this one movie, you [can] have the HBO decoding and decryption service used for that one movie, and then be removed from the device. By contrast, OSJi [provides] what we refer to as a long-lived services. When you push a service to OSJi, the service [remains on the device] until it is removed by the service provider. Jini offers short-lived services—there is leasing and clean-up when those services complete.

Finally, Roe described another of his company's Jini creations, a product that allows a car's stereo to play music from any MP3 player in the car. Since bytecodes representing a communication protocol with the device can be directly saved on the device, an MP3 player does not have to have a JVM in order to participate in the vehicle's audio network:

The problem we wanted to solve is, How do we accommodate all the mobile devices that are coming to the vehicle? You may have your mobile phone, an MP3 player, a DVD player, and you would want the car's stereo to play songs from all those.

It seems to be a pretty simple problem, but MP3 player manufacturers have a self-interest in locking you into a specific player: In order to play songs on a car stereo, you either have to have something as generic as an FM transmitter—where the sound is not good—or you have to have a special cable plug-in for your iPod, say. If you didn't buy that option when you bought the car, you are usually out of luck.

Our vision is that if you assume that that MP3 player has ... some sort of connectivity—for example, BlueTooth—it makes a network connection with a radio, and offer an MP3 service to that radio. It is now increasingly common to have some sort of JVM available in the car, including [for use] on the stereo system. The radio does not care what the manufacturer of that MP3 player is. It just looks for the MP3 interface and uses it. All it knows is that it can get a song and can play it.

In our prototype API, we use only two methods. One returns a list of songs when the radio comes in contact with the MP3 player. The user does not know where the song list came from - whether it was resident on the radio, or whether it came from the iPod, or whether it was resident on your son's MP3 player on the back seat. The other method then provides the data for a selected song.

What do you think of Roe's use of Java bytecode as a protocol to communicate with devices that can't run a full-fledged JVM? Would that be a generally applicable technique to interface from Java systems non-Java enterprise components?