Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo

Print-friendly Version

What are the biggest misconceptions that developers have about Jini network technology?

Probably the biggest misconception is that it is concerned primarily with devices. This was, unfortunately, the original marketing message used for Jini technology, so this misconception is to a large extent our own fault. It was one of those cases where an illustration of what Jini technology could do -- attach a device and it's found and used, detach the device and it disappears -- was mistakenly thought of as all that the technology could do.

The message about devices hid the fact that Jini software is really a general service-oriented architecture. Jini technology is really about advertising, finding, and using services on a network. Services are advertised by what they do, their Java technology interface, rather than what they are called, and the code needed to access the service can be dynamically downloaded from the service itself so that the client of the service need only know the Java interface. Devices are one way to implement a service, but there are lots of others, including software services.

Another common misconception is the belief that Jini technology is based on a proprietary network protocol, and so can't be used with XML, or CORBA, or SOAP, or some other communications mechanism. This misconception is somewhat more troubling, because it suggests that some people are missing what I think is the essential innovation on top of which Jini software is built.

"A lot of customers, once they experience the power of Jini technology, are unwilling to admit to it, because they don't want their competitors to know about it." - Jim Waldo, chief architect, Jini network technology

Most distributed systems are built on top of a wire protocol -- this is what allows communication to happen. The service knows what bits to put on the wire, and the client knows how to interpret those bits and respond. Both the client and the service are built with the code that knows how to take what is understood within the process that is doing the communication and translate that to the wire protocol, and to take the bits transmitted over the wire and translate them into something that can be understood by the receiving process.

Jini software changes this by leveraging the Java environment's ability to move objects, including the code for that object, from one place to another. So when a client finds a Jini service that the client wants to use, the client receives an implementation of the interface that identifies the service from the service itself. That implementation is responsible for the communication between the client and the service -- the client makes the calls that are defined in the interface, and the implementation of the interface is responsible for packing this up and transmitting it on the wire in such a way that the service can understand. So the service can use XML and SOAP, or CORBA, or even a protocol that it has invented especially for itself for the communication. The client doesn't have to know or care. In fact, different instances of services that implement the same interface can use very different communication mechanisms. Rather than using a proprietary protocol, Jini technology lets services use the protocol that is right for them.

What Ever Happened to Jini Technology?

Recently, I submitted the question, "Whatever happened to Jini?" in Google, and it pulled up 105 responses. One commentator, Daniel F. Savarese, wrote in Java Pro, "Ubiquitous computing seemed inevitable, and the quest to develop a framework for interoperability unerringly pointed toward Java. With Jini, Sun appeared to be developing the ideal solution. Still in the specification stage, Jini could not be assessed properly until it saw use in real applications. Four years later, Jini appears to be a niche technology used by a few applications. Why did this happen?" How do you respond to this?

One thing I've learned about this industry is that really fundamental change happens more slowly than most people expect. Ubiquitous computing is, in fact, happening, and Jini technology is being used, but neither have been instantaneous revolutions. These changes take time.

Jini technology is being used by quite a few customers. A lot of customers, once they experience the power of Jini technology, are unwilling to admit to it, because they don't want their competitors to know about it. This often happens with successful middleware. It can lead to the false impression that few companies are actually using it, so it must have failed. And then the word gets around and suddenly it seems like everyone is using it.

"Overnight success" can be a misnomer. It is the recognition of success that happens overnight. This may or not happen with Jini technology -- the jury is still out.

The Need for Connected Devices

Here is a question more consumer-oriented than technical: Will people want their devices to be connected in the way that Jini technology initially promised? Is there evidence that people will want or need for their stereo, TV, computer, refrigerator, alarm clock radio, cell phone, and car radio, etc., to be all connected and interacting? You have written that the world that Jini technology was created for does not exist. Do people want it to exist?

I've always been skeptical about many of the visions of ubiquitous computing, whether Jini technology-based or not. The idea that my refrigerator will know its contents and will suggest that I make certain dishes (or conspire with my stove and mixer to insure that I will) sounds like the Nutramatic machine from the Hitchhiker's Guide to the Galaxy -- which, after much analysis, always served you something that you didn't want. Many of these uses seem pretty silly to me.

But this is not to say that this technology won't be useful; it will be used in ways we don't currently envision. For instance, it would be useful for my car to be running constant diagnostics, to warn me of needed maintenance problems before they develop, and to give feedback to the auto manufacturers so that they can receive data to make a car that is more efficient, safer, and durable. I'd like my home appliances to be able to interact with the electric grid to conserve energy. And fairly simple medical monitoring connected to existing wireless telephone networks could decrease medical costs and save lives.

In my vision of the future of ubiquitous computing, the role of humans in the network is pretty minor. Most of the information will be passed to other computers, which will do the analysis of the data, and perhaps pass that analysis on to other computers. This is a different kind of network than those that we have designed, for the most part, in the past. Without human intervention, mechanisms for finding, navigating, and interaction will need to be designed to be used by machines and software objects, not people. And machines and software have very different capabilities and skills than humans. This will require a different approach to the construction of networks. That was one of the challenges we had when designing Jini technology, which was designed around machines and software objects interacting with other machines and software objects. We got a lot of it right, but there is a lot more that needs to be done in this area.

But not all of the questions regarding this subject are technical in nature. What do we want in such a world? For instance, insuring that the information collected benefits those it refers to is essential. Will the government be the guarantor of privacy, or will we need to protect ourselves against government intrusions?

I don't think that we can simply stop the trend towards ubiquitous computing. Its efficiencies are too large, and benefits are too great, and its savings too significant. We need to ask the right set of questions at the beginning of the process, and not wait until the technology dictates the answers.

Moore's Law and Distributed Computing

As computers and networks expand and get faster, as Moore's law unfolds, and processing can be done on a server, and people rely increasingly on thin clients, is the role of distributed computing diminished?

I've been hearing about powerful computers leading to the demise of distributed computing for about 20 years now, and remain skeptical. Part of my skepticism is based on how people use computers. Much of what we do is to work together on common projects, share ideas, and write things that will be used by others. This is easy to do if we all share the same machine, but we rarely know or anticipate accurately everyone with whom we'll be working. So we need to be able to connect our machines so we can work with those who are using another machine. Everyone working on the same machine is not going to happen no matter what Moore's law says. So the only alternative is to knit our machines together, and that means that we need distributed computing.

Another reason I'm skeptical has to do with mathematics. The kinds of chips Moore's law describes are, essentially, two-dimensional. Doubling the capacity of a chip, either by making the components half the size, or by making the chip larger, gives you four times the component count, which is about what is needed to double the speed of the chip.

But networks are not two-dimensional. It is an interesting question as to what the actual dimensionality of a network is, measured as the average number of connections between points. Some research that I've read shows that the dimensionality is some fractal between 7 and 8. This means that as the network doubles in size (the number of nodes, or points) the volume of the network (a measure of the number of interconnections) goes up by some power of between 7 and 8. So networks are getting more connected faster than processing power is going up.

Thus, more data, more users, and more traffic are on the network than the machines can handle. Rather than needing to concentrate our processing on larger and larger machines, the mathematics of the network dictate that we need to move the processing out into the network itself, spreading all of the requests for processing out to more processors, not fewer. So I think that distributed computing is going to be more necessary, not less, as we progress.

Programming Distributed Systems

You co-authored an influential paper on distributed computing in 1994 in which you argued that objects interacting in a distributed system must be dealt with differently from objects that interact in a single address space. You argued that distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure. Looking back a decade later, what take-home insights would you offer developers that relate to these ideas?

"A Note on Distributed Computing" was an attempt to lay out a basic argument against the received wisdom of the time, which was that the goal of distributed computing infrastructures was to make programming a distributed system look just like programming a non-distributed system. My co-authors and I argued that if you did that, you would be doomed to building distributed systems that were unreliable.

"It would be useful for my car to be running constant diagnostics, to warn me of needed maintenance problems before they develop, and to give feedback to the auto manufacturers so that they can receive data to make a car that is more efficient, safer, and durable." - Jim Waldo, chief architect, Jini network technology

There has been progress in this area. The Java environment's Remote Method Invocation (RMI) system requires that programmers mark methods that call to another address space by declaring that those methods throw a RemoteException, which must be handled by the caller. This isn't surprising since RMI was designed and implemented by Ann Wollrath, who was a co-author of "A Note". But it means that a lot of Java programmers understand, or at least are forced to program as if they understand, that making remote calls is different than making local calls.

Unfortunately, not everyone is convinced. There are still those who try to produce middleware that masks the difference between local and remote calls. And then there are those who try to avoid the problem by claiming that they are not subject to the errors that we talked about. I'm constantly amazed by people who say that they don't have to worry about the difference between local and remote computing because they use "reliable message systems." I've been known to claim that there are two kinds of reliable message systems. The first kind are those that come with an asterisk; following the asterisk leads you to the small print, where you find out when the messaging system can fail and so it is not, therefore, reliable. The second kind are those systems that simply lie -- they are no more reliable, but they don't tell you that there are circumstances where they can fail.

A friend of mine once characterized the majority of computer scientists as people who would rather spend weeks of hard hacking than an afternoon in the library. I'm afraid that describes many in the distributed computing community today. The end result is that we make the same mistakes over and over, trying to do what can't be done. But progress happens when practitioners understand the intrinsic difference in programming that the network introduces. We have a long way to go before all of us understand this.

The Appropriate Role of Standards Bodies

You have written that, "Common wisdom, especially in distributed computing, says that the right approach to all problems is to use a standard. This common wisdom has no basis in fact or history, and is curtailing innovation and rewarding bad behavior." You argue that good technology is created by small groups and not by large committees.

My point is that standards bodies are the wrong place to try to innovate. The right thing for standards bodies to do is to take a de facto standard (that is, a technology that is already pervasive in a particular domain) and turn it into a de jure standard (that is, one that is officially recognized). This was the role of standards groups with TCP/IP, and with the C language, and (originally) with HTML.

Watch out when a standards body tries to create a standard from scratch, or tries to make significant alterations in a de facto standard on the way to making that technology a de jure standard. Standards groups, for the most part, are political bodies rather than technical bodies. They work by reaching consensus, by compromise, and by making deals.

Good technology and innovation occur when small groups of smart people try to solve a problem in the most elegant fashion -- groups that are unwilling to do what's acceptable over what's right. Once the right thing is identified, and it is seen by everyone else to be the right thing (and that is determined by a rather long process in the marketplace, and unfortunately doesn't always occur), it is fine for a standards body to anoint that solution by making it a standard. But this is an act of recognition, not an act of creation.

The Poetry of Programming

In December 2002, Sun Distinguished Engineer Richard Gabriel spoke in an interview about programming as an activity more like art than science. He argued that programming is not a pure engineering activity -- assuming that there is such a thing. In creating software, developers are often trying to create something genuinely new, while most other engineering involves creating something that has been built thousands of times before. He argued that we should train developers the way we train poets and artists. You have made similar points about the kind of apprenticeship that developers must undertake. What is the role of craft and aesthetics? And can it be taught? Is there a set of guidelines or rules to follow that can assure that a group will produce quality software?

Programming is a creative endeavor. There are lots of decisions that have to be made, and an overall structure that needs to be constructed. So, like any other activity that requires creation and the construction of something that is new, programming has a lot of craft, aesthetics, and taste that go in to the making of a good system.

I don't think that we know how to teach good design in any way other than by letting people try to design something and then tell them where they got it wrong, where they got it right, and how they might have done it differently. A lot of this isn't really wrong or right, but rather better or worse, which makes it even harder.

This is definitely something that can be taught, or to be more precise, is learned since you can only teach someone who is actively learning. But in my experience, there is no sure-fire technique to hand over knowledge and skill. And there is certainly no process, or technique, or set of rules that will guarantee the production of good software other than getting people who have produced good software in the past to do it again. They may program in the same way, or in a completely different way. Different groups will produce good software in different ways, and the same group will use different approaches in different circumstances.

I keep a poster from the movie The Magnificent Seven in my office to remind me of how a good programming team works. Under the best conditions, you get together a small group of professionals. You don't try to tell them what to do in any but the most general way. And if you find someone with real promise (in the movie, there was a kid who could catch fish in his bare hands) you let him or her learn by doing. All of the most successful teams I've been involved with used some variant of this approach. This isn't to say that this is the only way to teach, or to produce good software, but it is the only way I know.

See Also

Jini.org
The Poetry of Programming
The Jini Community
Jini Network Technology
Jini Specifications and API Archive
Jini Network Technology Installation Instructions Index
Jini Network Technology Archive
A Note on Distributed Computing