Interview by Christy Hudgins-Bonafield with Jim Waldo, Sun's Chief Jini Architect
Q: What is the most important thing Jini will bring to those who manage networks?

Waldo: Figure out how much you spend installing new equipment into your network. Installing is a labor-intensive task, so is configuring. You have to get the right DNS match. All this swill. The Jini way of installing is to plug into a wall socket and the network and walk away. Then, subtract that from the budget. But it actually has a much deeper advantage, but one IT managers and others may have difficulty understanding. It allows for a way of dynamically changing the network that currently is impossible. Now, if you want to walk into a conference room with a number of other people having a meeting you might take your laptop, but you don't expect to use the printer or get a fax sent while you are there. You don't bother plugging in because by the time the machine is configured and the drivers are loaded, the meeting has been over for two days. In a Jini world, everyone plugs in and sees the resources. They are able to use the printer and fax and see things people are posting on whiteboards that are shared. Rather than the network being this hard to change static thing, it is a very spontaneous piece of organizational structure that can reorganize itself as easily as people reorganize themselves.

Q: What is the primary purpose of Jini?

Waldo: It's primarily for discovery and installation. It erases the distinction between hardware and software. They are just different ways of implementing a service, and a service is presented via a Java interface. So, some services may be entirely software running on a standard computer with a JVM; others may be entirely hardware with a very thin veneer of Java code on the client side that talks to the service. And the client need not know the difference in the two. It's one of the more significant breakthroughs we have made. Of course, we have an unfair advantage in a Java universe that lets us move code around. We move code from the device into the lookup service and use that as what the client receives when it looks up the service. It allows the service to provide the client with the code needed to talk to the service.

Q: I've seen reports that Jini is a replacement for the OS. Is it?

Waldo: Distributed OS is a label given to Jini by people who don't understand what we are trying to do. People have tried to extend an OS across the network. I don't think that works. We aren't trying to replace the OS, but enhance the OS above the level of the OS, so that it allows interaction among operating systems. We are trying to make operating systems less interesting. Jini was designed to work well with Unix, Windows, Macintosh and Linux operating systems. The OS will be relevant for the device it's running on, but as far as the network is concerned it is irrelevant. It's possible you could use Jini to change the way you organize the components currently united by an OS. Today the OS takes care of a disk and a CD and a CPU and makes sure they work together. We do foresee a world in which Jini allows you to plug these components in the network and offer them as services. We have demonstrations of it already. It's a question of how soon device manufacturers can put these things out. It's quite possible we'll see Jini devices by early to the middle of next year. What you finally get is something a little different from plugging a disk drive in the PC and the OS picking it up. If you plug Jini in you can use it, but anyone else can use it as well, depending on security restrictions and configuration. It's a network federation system.

Q: How does Java take advantage of Jini and Jini take advantage of Java?

Waldo: Jini requires Java-we use the portable object code allowed by Java, the ability to have safe, verifiable code, and we make use of the Java type system. Java is an enabling platform for Jini. Java can take advantage of Jini since Jini essentially moves Java from the single machine environment to the network.

Q: What are the most significant differences in a Jini-enabled device and a machine running a full Java Virtual Machine?

Waldo: A machine running a JVM can be very easily Jini-enabled. The amount of code needed to enable such a machine as a client is about 48 KB. But you can have a Jini-enabled device not running a JVM. We can utilize the network as long as there is a device somewhere on the network that is running a JVM and is willing to act as a proxy for the device. The device can, with a very small amount of code, in the hundreds of bytes, become Jini-enabled in that situation.

Q: Jini-enabled devices must have their own processing and memory or use those of a proxy. I understand requirements vary. What is the range in memory required for individual devices?

Waldo: It will depend on what the device is doing. At the very low end the Jini requirements are 48KB. Large compute servers can never have enough. If you had a Jini service-and one of the first we've done is JavaSpaces, which is somewhere between a file system and a database and provides persistent network storage-well, we've done some back of the envelope designs for a JavaSpaces implemented entirely in hardware, using hardware matching and direct to disk storage, and for a device such as that we'll take as much memory as you'll give. The more memory, the better the performance.

Q: How can older devices be retrofitted to accommodate memory requirements? Can you describe the proxy system you use?

Waldo: The idea of a proxy is that you have a device that exists on the network that is probably running a JVM and is willing to act as the front entity for a device that doesn't have those capabilities. In such a case, the device without capabilities could find a proxy in order to be a full Jini citizen. This could be done through a private protocol and once [the JVM] was found it would give the small amount of information needed to describe how to interact and the proxy would interact with Jini. It could be for a single device or dozens of less competent devices.

Q: So, would this multidevice translator be a proxy server?

Waldo: I wouldn't call it that since there are already proxy servers for a different purpose. We'd have to invent a new name. A Jini mouthpiece maybe. We have existing partners expressing an interest in getting together.

Q: You have to have a JVM somewhere on a network to Jini-enable a device (unless it has its own JVM). Does this JVM have to be dedicated to the individual device being Jini-enabled or can a JVM handle many Jini devices-and if so, how many?

Waldo: A JVM proxy can handle a number of devices. I would expect that a single proxy could handle hundreds of devices.

Q: Who are your partners? What type of equipment do they have?

Waldo: All I can say is consumer electronics devices that are very small and cheap and don't have much smarts.

Q: So, they are coming up with hardware to do this?

Waldo: This proxy can be software that lives in your home computer if you wish. It doesn't have to be hardware. You could do it in hardware, but I expect the first implementations will be done in software because it is more plastic.

Q: In your prototypes didn't you rely on pocket-sized hardware?

Waldo: We have some adapters. A partner did those.

Q: Will the adapters remain pocket-sized?

Waldo: Right now the ones we are seeing are about pocket-sized. They're quick prototypes. The adaptation needed could be exceptionally small. It screams out for implementation in silicon.

Q: So, when will we see that from Sun?

Waldo: I'm a simple engineer, ma'am. It would surprise me is Sun didn't do this, but I've been surprised before.

Q: Do the drivers in a Jini-enabled device need to be written in Java?

Waldo: They aren't really drivers-they are the network equivalent of drivers; code that can be used to talk to the device over the network. They need to be written in Java since they need to be downloaded into any client that wants to make use of the service.

Q: What will be the first three Jini-enabled devices most relevant to businesses?

Waldo: The multifunction devices-printer-scanner-fax combinations, because they are a nightmare to get device drivers on and plug-and-play doesn't work for them, so those people are quite interested in Jini. On clients, it would be the laptops. People want to bring them in and have plug-and-play that works. The third would be storage devices. So, the first things will be standard computing devices. The next round will be things we don't think of as computing devices but can be-things like cell phones, CD drives, scanners, digital cameras and automobiles.

Q: How many products will be enabled over the next 12 months?

Waldo: I don't know, but we have been staggered by the response. We currently have more than 20 companies that have signed up and we are in negotiation with more companies than are signed, and the technology isn't even available to the public yet.

Q: If every time a user plugs into the network he or she has to download all the drivers for that machine, won't it be frustrating?

Waldo: Once the driver is there it can stay there. It doesn't have to be downloaded every time. We bring it over and check if the code is there and if it is there we don't download.

Q: Can you use Jini to prolong the life of older machines without a 32-bit architecture on a network?

Waldo: You could use Jini to take machines without a 32-bit architecture and have them provide services on a network of machines with a very small veneer of Java code that may be running on a 32-bit machine that is fronting for the older machine. The older machines without much knowledge of Java can offer a service by having a small piece of Java code that talks to an equally small piece of Java or non-Java code on the machine, and that code could implement the service over the network.

Q: What types of capabilities would this give the older machine? Would it be similar to having a JVM?

Waldo: You wouldn't have quite the flexibility on the older machines that you have with the newer machines. You could use them for processing or storage or remote sensing or other similar purposes on the network.

Q: So, the network is the computer ?

Waldo: Yes, we finally understand what that means.

Q: Lets talk about the architecture for a moment. The primary components, then, are Jini enablement of a device or program, a discovery protocol that registers this object with the network and a lookup box that records where an object lives and how to obtain its drivers, associated code or other features?

Waldo: The lookup service doesn't have to be a box. Even the client can act as the lookup service. The discovery protocol is really the core of Jini. One of our guiding philosophies is that Jini should be small and simple.

Q: What protocol are you using for discovery?

Waldo: The current protocol is our own protocol. It's a packet of our own [that a device sends over the network as a multicast when it is plugged into the network]. We are talking to the Service Location Protocol people about combining the two. The Service Location Protocol is something that has been proposed to the IETF that is somewhat different in scope than ours. The Jini Lookup and Discovery is meant to work for the workgroup side, for between one and 100 people. This has to do with the user interface aspects of Jini. The service keeps a fairly flat listing and lets you organize the listing on the fly, depending on the attributes specified and the Java type of the services you are looking for. Because of this there is no hierarchical listing and we think it scales best to the workgroup. This is because people can't look through more entries than that. It's useful, too, for me to find the printers in my building, but not terribly useful for me to find the printers in a building in another part of the country.

Q: Couldn't you rely on programs for this lookup?

Waldo: Yes, programs could also do it, but they are probably less good than people in making choices. I think it might scale worse. It is an area of continued work that we are doing. What became Jini started off in about 1991 or 1992 when I joined Sun Labs and I was trying to figure out how to present a large network of millions of machines in a way users could understand. I still don't know the answer, but I figured out how to understand flexible networks of hundreds to thousands of machines.

Q: I thought I saw references to the lookup service being hierarchical, rather than flat?

Waldo: A lookup service can be entered in another lookup service, which provides the hierarchy.

Q: I see references to a boot, join and discover protocol. Are there multiple protocols here?

Waldo: No, there is one protocol for all of this. We started off calling the [discovery] protocol boot and join until marketing got hold of it.

Q: As each device announces its existence, attributes and capabilities to the network, it would seem that you'd have a very long attribute list, much like a management information base, with extended proprietary attributes. How do you handle this in the lookup service?

Waldo: It works like a JavaSpace, but unlike a JavaSpace, it only requires that something match the things you put in. Not everything. If it says, "I'm a printer with color and seven proprietary attributes" it would be matched by someone who says I want to find a printer. Or the person could describe the specific proprietary attribute needed. If you just said I want the closest printer on this floor it would give you [that printer].

Q: How likely is it that Jini will incorporate the device specific attribute specifications of the Salutation consortium for things like fax, multifunction devices, scanners and printers?

Waldo: The devices can fit into the current Jini framework easily. There is no need for device-specific attributes in Jini.

Q: How likely is it that Jini would change out its discovery protocol in favor of a polling protocol like that of the Salutation Consortium?

Waldo: Unlikely. Polling doesn't scale. Polling actually takes more bandwidth than notification.

Q: Can you describe how JavaSpaces works?

Waldo: JavaSpaces are like a network accessible bulletin board. You can put up groups of Java objects and look for groups of Java objects and take groups out. It's shared among entities on the network and it is persistent. You can go away and the objects will still be there, and it has an interesting way of finding objects. You find them by presenting a template-a kind of fill-in-the-blank. "Give me a group of objects that match the kinds I'm looking for." But you can also supply a value for any object and the only thing returned has to match exactly, for example, a "color" printer.

Q: So, JavaSpaces could run as a service atop the lookup service, which functions as a directory?

Waldo: It's sort of like a directory service and sort of not. It returns Java objects rather than references. It's not language-independent and it doesn't scale because of the user interface, which was a conscious decision. Some people confuse the lookup with a directory service. It's a registration service for the people inside the workgroup, but we are already working with Novell on a Jini-enabled directory service.

Q: Will you create your own enablement for Microsoft directories?

Waldo: Possibly, but we'd rather have Microsoft do that.

Q: Whenever you deal with technology there are trade-offs. What are the primary trade-offs you had to make with Jini?

Waldo: At least in the early development of the technology, we didn't worry about how it would fit in the existing world. We took a fairly radical approach to design this from the ground up and do it right. Only after we were done did we try to figure out ways to plug it into the existing world. The thing we consciously gave up was control. If Jini becomes ubiquitous it doesn't mean we get the kind of secondary control over devices and computing technologies that some companies get because of their dominance in operating systems. We won't be able to leverage Jini because Jini is simple enough others can understand it as well as we do before very long. I'm enough of an anarchist that I believe this is a good thing. We don't plan on making tons of money off of Jini. Our current thought is to take the open source model and give the technology away. It's more interesting if its ubiquitous. The money to be made is in services accessed over the network. Clearly, we think Sun will provide some of those services, but we won't provide all of them.

Q: What will be some of the first services we'll see?

Waldo: Services that would take storage requirements and channel them to the right device. In this respect, I hope JavaSpaces will be immensely popular. I genuinely hope others in Sun are also thinking of services I haven't thought of. I'm a distributed computing wonk, not a services wonk.

Q: What about security?

Waldo: Because we are assuming Jini is at the workgroup level, the first version doesn't have security beyond the Java safety requirements. It works within a sandbox with the full Java security mode, but there's no authentication and access control. We are adding that with the next release of Jini. One reason it's not in the first release is that we were unwilling to put out a security system that didn't deal well with the delegation of identity from one entity to another. In an object-oriented system, you have to give away some of your rights. It's a classic problem of distributed security. We weren't sure at first that we knew the answer, but we now think we are close and we are committed to this in the next major Jini release. Of course that's the next release and we are only hitting beta now.

Q: What protocols and networks will Jini work over today and in the future?

Waldo: Today it works over TCP/IP and any network that can be used in a way that allows a socket level abstraction. Jini itself is based on the Remote Method Invocation, RMI, system of Java, and that system is designed to allow various transports to plug in transparently. It has been ported to fast computer experimental protocols.

Q: What about CORBA?

Waldo: CORBA has a rather different architecture so work is going on to put RMI on top of IIOP and this requires changes in IIOP and those are things we don't control. It's done by the OMG. CORBA has a different set of assumptions than we make inside Jini and RMI and because of that some of the functionality that is necessary is not really available in CORBA. CORBA, for example, doesn't allow you to move code from one CORBA process to another. I was Hewlett-Packard's CORBA architect before coming to Sun. We've done the best we can to get the two systems together. CORBA services can easily fit into the Jini world by having a Java interface and once you get beyond the Java interface how the service is implemented on the inside is up to the service itself. The way you hook into non-TCP/IP protocols is to have those protocols pluggable into RMI, the version of RMI in JDK 1.2. That is the version that allows you to plug transports into RMI.

Q: What does it mean that Jini uses separate JVMs to run Java objects? Do you have JVMs on top of JVMs?

Waldo: A Jini service can run in a JVM or outside a JVM. The way the underlying method invocation system works if there are multiple services on the same device, which is probably a good-sized computer offering multiple services, you can configure it in such a way those services run in separate JVMs to ensure that they don't interfere with the other services.

Q: Earlier when I talked about trade-offs with Jini I was thinking more along the line of what boundaries have been drawn around the technology. For example, can you use it for remote users over a 28.8 modem?

Waldo: That depends on what you are trying to do. RMI was designed for Ethernet-style throughput . I'm an adjunct professor at Harvard and I teach a distributed computing course there and I had students doing a distributed game with three players and one was over PPP with a 28.8-Kbps modem and it worked. I was surprised. So, I would say, depending on what you want to do, it can work remotely. But to be honest we developed Jini with the expectation that bandwidth would increase dramatically over the next couple of years. I worried about Jini in the home when my home connection was 28.8. I have a cable modem now and I'm not worried anymore.

Q: Did it work with 28.8?

Waldo: I didn't try.

Q: What are the technological pros and cons of Jini versus Microsoft's Millennium?

Waldo: Millennium is a research effort designed to produce a network operating system. Jini is a product. Millennium is something that would be more complex than a single machine operating system, and attempt to have centralized control over a group of machines. Jini is not an operating system (it relies on their being some operating system on all of the machines); it is a simple mechanism to allow federation of the machines. This allows it to be simple, small and reliable.

Q: Microsoft says that Java RMI only lets objects communicate with each other if the programmer follows a specific set of rules-that using RMI the developer must modify source code to make the program distributed. With Microsoft's Borg the program just runs and Borg automatically makes the program distributed without requiring any source-code modification or effort on the part of the programmer. Is this correct?

Waldo: The goal of making distribution transparent has been tried for a long time, and it doesn't work (see "A Note on Distributed Computing," www.sunlabs.com/technical-reports/1994/abstract-29). Microsoft may think that they can do this, but the fact is that no one has ever succeeded, and for good reason.

Q: Microsoft says that the primary difference in Jini and Millennium is that Jini is a telephone infrastructure between distributed programs (which Microsoft already has) and Millennium will make the network completely invisible to the applications-that a network of computers will look like a single supercomputer. Again, what is your take on this?

Waldo: Again, there is no way to have both a reliable distributed system and hide the network. The early comments by Microsoft (that Jini is a telephone infrastructure) indicated that they don't understand the technology.