The Jini Vision
by Bill Venners
August 15, 1999

First published in JavaWorld, August 1999
Summary
This article attempts to explain not how Jini works, but why it exists. It illuminates on the unique value of Jini technology, reports on the recent Jini Community Summit, and considers Bill Joy's comments on his creation.

I first read about Jini last summer in an article in the San Jose Mercury News. In the year since then, I've struggled not only to come up to speed on the technology, but also to understand its implications. Fortunately, I've had the opportunity to collect insights from many of the people at Sun who shaped the technology. In this article, I'll tell you what I learned, based mainly on my discussion about Jini with Bill Joy at the recent Jini Community Summit and on my interview with James Gosling prior to the 1999 JavaOne Developer Conference.

Another hardware revolution on the horizon?
On May 19, I flew to Aspen, CO, to attend the first Jini Community Summit. I went to Aspen to learn more about Jini, to see what other people are doing with it, and to attempt to figure out what the Jini community is all about. The first person I met was Torin Sarasas, with whom I had agreed over e-mail to share the expenses of a hotel room. At 6:30 that evening, Torin and I walked over to the community center for an informal cocktail reception. Being rather hungry, I dragged Torin over to a table of cheese, crackers, and vegetables, where I filled up a plate. Then we set out to mingle.

We wandered from group to group, mingling with people and conversing on a variety of topics. One topic that seemed to come up again and again was the rumor that a wireless network of some kind blanketed all of Aspen. I had heard this somewhere before, but I didn't know any details. No one in the groups I landed in seemed to know anything concrete either, but at one point I looked over and recognized somebody who probably would know. "Hey, that's Bill Joy over there," I said to Torin, who said, "Wow." Both Torin and I have always held the utmost respect for Joy because of the high caliber of his technical creations. For a few moments, we both stood and looked at him in awe. Then we rejoined the conversation of our group of people.

Joy was also in a mingling mood, and before long he walked over to our little circle of people. He didn't seem to know anyone in our group, so to get the conversation going, I asked him about the Aspen wireless network rumor. He confirmed the network's existence, informing us that it in fact reaches all the way down to the border of Utah. Even though the wireless network covers about 100 square miles, he told us, it actually consists of a single class C Ethernet network. Joy added that the wireless network works very well, and predicted that every major city will have something like it by 2007. So the rumor was true.

Later that evening, a Jini Community Summit attendee informed me he had checked his e-mail on a small device connected to the Internet via this wireless network. I walked outside onto the patio and located the device and its owner. The gadget in question, which was sitting in the middle of a table on the patio, was a small PC with a tiny keyboard, a tiny screen, and what appeared to be a PCMCIA network card sticking out of its side. I was granted permission to use it, so I leaned over this small PC, fired up telnet to connect to my ISP, ran pine, and read and replied to my e-mail.

Chips and bandwidth
As I worked through my e-mail on the small device, I had a strong sense that my simple act offered a glimpse of things to come. Two emerging hardware trends were to some extent already represented on that patio: the proliferation of small embedded devices -- anything with a microprocessor embedded in it that has a relatively focused functionality -- and the proliferation of high-speed, ubiquitous networks. I was impressed by two things as I checked my e-mail that day: the speed of Aspen's wireless Internet connection, and the complete lack of any wires or cords leading to the PC on the table. The device didn't contain a power cord or network cable. Checking my e-mail involved only me, the device, the electromagnetic spectrum, and a nice view of the mountains.

Examples of embedded devices include cell phones, microwave ovens, VCRs, pagers, clocks, and printers. Although a PC contains an embedded microprocessor, it isn't usually considered an embedded device because it doesn't have a focused functionality. Rather, a PC is a general platform suitable for running many kinds of software. A microprocessor-enhanced typewriter is an embedded device, focused on the job of typing. A PC running a word processor can serve the same purpose as the typewriter, but the PC doesn't qualify as an embedded device because that same PC could be used to run a spreadsheet, surf the Web, or play solitaire.

System on a chip
The proliferation of embedded devices is being driven by the decreasing costs of adding processing power to devices, which is a result of increasing the functionality of the chips -- or chip -- embedded in a system. The morning following the cocktail reception, Bill Joy gave a presentation called "The Jini Vision." During this presentation, Joy said that the personal computer revolution was spawned when Steve Wozniak, cofounder of Apple, fit everything for a computer onto a single motherboard. The single-motherboard computer, a simple but fundamental change in the hardware status quo, made it less expensive to build computers. These days, Joy continued, entire computers can be placed onto a single chip, which he called "systems on a chip." Putting an entire device on a chip, he said, makes the device cheap and reliable. At that point a fellow sitting in the audience, Bruce Christopher, mentioned that his company, a startup called JCan, is doing exactly what Bill Joy was describing. JCan is developing a chip based on Sun's picoJava core that will include the Java and Jini APIs on the chip. Christopher said he hopes to get the cost of his chip, which he called a "silicon motherboard," down to $10 in five years.

As both the cost and size of computers continue to decrease, it becomes cost-effective to include processors in more and more kinds of products. To add value to their products, manufacturers will be enhancing them with embedded processors. In the coming years, this trend will yield an explosion of embedded devices.

Connecting to high-speed networks
The other trend underway in the hardware world is the proliferation of high-speed networks. Companies are basically tripping over themselves to build this infrastructure, spending billions of dollars along the way. High-speed backbones are being built. High-bandwidth pipes are being sent into homes. Wireless networks are being developed. Increasingly over the next decade, the network will be fast, and the network will be everywhere.

The current trends in the hardware world point to a future in which more and more devices that we use every day will be enhanced with embedded processors and interconnected via networks. Over time, our environment will become "smarter," and this promises to bring profound changes in how we do things at work, at home, and everywhere else.

The disappearing computer
One way to describe the coming trends in hardware, a concept that came up a few times at the Jini Community Summit, is the disappearing computer. According to Richard Gabriel, the Summit's emcee, if you look in the 1898 Sears & Roebuck catalog, you can find something called a home motor. In those days, you could buy a general-purpose motor, bring it home, and hook it up to anything that needed turning. Nowadays, consumers aren't inclined to purchase general-purpose motors for the home, and the home motors they do purchase aren't usually thought of as motors. When you purchase a fan for your home, for example, you purchase a motor, but the motor is an integral part of the fan. The motor's sole purpose is to turn the fan. Motors also reside in the home as part of heating systems, refrigerators, dishwashers, washing machines, clothes dryers, hair dryers, lawn mowers, and so on. You can think of all these motors as embedded motors -- motors that are part of devices or machines focused on specific tasks. As motors became smaller and cheaper, the general-purpose home motor, as advertised in the Sears catalog, disappeared into a proliferation of motor-enhanced devices and machines with focused functionalities.

Today, you can go to Sears and buy a general-purpose home computer. But like the motor, the computer may be destined to disappear, over time, into devices and machines with more focused functionalities. Today, motors surround us, but we don't often think about them individually. We think more in terms of the devices and machines in which the motors are embedded. In the coming years, computers will increasingly surround us as embedded devices, but we'll think of them as computers less and less. As computers become embedded inside the things we use every day, they will "disappear" from view.

During his presentation, Bill Joy claimed PCs have four basic types of application: "spreadsheets and word processors and spreadsheets and word processors." In other words, as Joy put it, the only kinds of applications desktop computers are really suited for are spreadsheets and word processors. But, as he pointed out, most people don't do word processing or spreadsheets. "Web and e-mail is what people care about when they turn the machine on," he said. As a result, Joy claimed, "Many people would prefer a simple machine that is more communications-oriented."

The demise of the desktop
At one point in our conversation at the cocktail reception, Bill Joy pulled out his cell phone and began imagining aloud how he would want to do computing in the coming world of embedded devices and ubiquitous networks. He described a flat-panel display currently being manufactured that can be folded or rolled like paper. He said that in the future when he needed to do some work, he'd set down his "handset" (represented by the cell phone), and roll out his flat-panel display. The handset would have a wireless connection to the Internet and a wireless connection to the display. "Forget the desktop," Joy said.

Although Joy's main thrust was predicting the demise of the desktop, what really struck me about this part of our conversation was the foldable display device that he described. It occurred to me that you could think about this device in two ways: as a flat-panel display able to be folded and curled up like a piece of paper, or as "smart paper." I felt this was an excellent example of how computers will be disappearing into devices we use every day, often in surprising ways. It had never before occurred to me that such a ubiquitous entity as paper could become an embedded device.

Jini: A software infrastructure for the hardware revolution
The first talk about Jini I ever heard was given by Jim Waldo, Sun's enthusiastic chief Jini architect, at a Java users group meeting in New York last December. Waldo started his talk by claiming that Jini was not an attempt to wrap existing operating systems, but was an attempt to "change fundamentally the architecture of computing systems." While everyone is in a frenzy about the Internet these days, he noted that the Net itself doesn't represent the fundamental change that's coursing through computing. "The Internet is a symptom of what's really going on," Waldo said. "What's really going on," he continued, "is a switch in the way we think about computers: The network is becoming a central part of what we think of as a computer ... Computers have stopped being computing devices and have started being communication devices."

Waldo then described how in a fit of nerdy enthusiasm one Saturday afternoon, he took a screwdriver to his microwave oven to see what kind of processor was inside. "I know," he said, "I should go down to the video store and rent a life." Embedded in the guts of his microwave oven, Waldo discovered a Motorola 68000 processor, which happened to be the kind of processor used by his very first Sun workstation. It occurred to him at that point that, "I could run V7 Unix on my microwave oven!" Microwave ovens are computers, he told the audience, but "we don't usually think of microwave ovens as computers, because they lack one of the three parts we've traditionally thought of as making up a computer ... a CPU, some memory, and a disk." The microwave oven has a CPU and some memory, but no disk.

Waldo then went on to describe three common assumptions about software in the traditional, disk-centric world:

  • Our software assumes it will always have local storage
  • There is an intimate connection between CPU and disk
  • There is a tight binding between code and the processor

"Since disk drives keep getting bigger," Waldo claimed, "we put all our software on the disk." To demonstrate what he meant by "big," he said that the estimated size of the software required for President Reagan's Star Wars missile defense system was 30 million lines of code. The size of Microsoft's current Windows operating system is 45 to 60 million lines of code. "Solaris isn't that much better," Waldo added. "It is smaller, but not much smaller."

According to Waldo, one of the reasons the Star Wars project was cancelled was due to the belief that it was impossible for human beings to create a 30-million-line program that worked reliably. "Admittedly," he said, "the blue screen of death doesn't fire lasers at you."

Waldo believes OSs have become so large "because the operating system has to know about everything." Given the rising importance of diskless, network-connected embedded devices, however, "this [disk-centric] model [for computing] doesn't fit anymore," stated Waldo.

He went on to say that the emerging hardware environment will be dominated by computers that have a CPU, some memory, and a network connection. And, whereas traditional computers look on startup for a disk from which to boot the operating system, the new devices will look for the network. "When a cell phone boots up, it checks itself and then looks for the [phone] network. If it doesn't find the network, it isn't a cell phone."

Given this background, Waldo explained how Jini attempts to provide an architecture for the emerging network-centric hardware environment, an architecture based on the idea of a federation rather than central control. (For more on the federation concept, see the introductory Jiniology column, "Jini: New technology for a networked world" -- in Resources.) "Jini is not an operating system," Waldo insisted, "because nothing in Jini knows or controls everything. [Rather,] Jini defines a small set of rules that enable clients and services to interact. Jini defines the rules of federation." The implication here was that because Jini doesn't involve a central controlling authority, its runtime infrastructure can come in well below 30 to 65 million lines of code (and thus be more robust than Windows or Star Wars). As Jim Waldo put it, "All of Jini can fit on a single 1.4 MB floppy." In addition, Jini's lack of a central controlling authority means Jini systems lack a central point of failure that can bring everything to a halt.

The mobility of objects
During Bill Joy's presentation at the Jini Community Summit in May, he showed several "stacks" that represented various stages in the evolution of the computing model. The last stack he showed represented the computing model that Joy claims is now emerging. It was labeled "object-centric." (See Figure 1.) In this stack, devices and services (the bottom layer) expose objects (the middle layer) used by client applications (the top layer). Joy said the Java virtual machine, RMI, and Jini provide the central layer, labeled "Objects and Agents." "We think of this [middle layer] as a BIOS," he said. By calling the middle layer a BIOS (basic input/output system), Joy was claiming that objects (such as those supplied by a Java/RMI/Jini infrastructure) would provide the basic means for applications to talk to the "computer" represented by the network -- a computer made up of a federation of devices and services.

Figure 1. An object-centric network stack

Was Jini the 'Vision' all along?
Bill Joy's calling the Java/Jini layer a BIOS made an impression on me. When I wrote my book Inside the Java Virtual Machine three years ago, I spent the first four chapters describing Java's architecture and presenting my opinions on the why it was designed the way it was. Looking back, I think that for the most part I got it right, but one concept wasn't exactly there. In my book, I concluded that the point of Java's architecture was to enable the network mobility of software. I still agree with that, but, in those days, when I used the phrase network mobility of software, I was thinking about network mobility of code: in other words, the kind of software mobility demonstrated by the Java applet. As I learned about Jini in the fall of 1998, however, it began to dawn on me that perhaps the point of Java's architecture was not only to enable the network mobility of code, but the network mobility of objects -- to make possible an object-oriented "BIOS" for a network computer.

This past April I had the opportunity to meet Nigel Warren, coauthor of the book Java in Practice, at a small C++/Java conference in Oxford, England. Over coffee Nigel told me he had a suspicion that Bill Joy was the central force behind the entire Java effort at Sun, and that he has pushed the Java effort in directions that would help him realize his vision of Jini. Now, I'm not usually one to believe conspiracy theories whispered into my ear, but Nigel's suspicions made me curious. I had heard that Java was originally envisioned for embedded devices. To what extent, I wondered, was Java's original purpose to provide a platform on which a Jini-like infrastructure could be built? Nigel and I agreed to try to get an answer to this question.

Therefore, when I found myself in Aspen one month later, serendipitously standing a few feet away from Bill Joy as he described the Aspen wireless network, I decided to ask him the question directly. "To what extent," I asked, "was Java created with what eventually came to be called Jini in mind?" Joy replied, "We knew about Jini in '94 and '95 when we directed Java onto the Web." And the next morning during his presentation, Joy said, "We built the JVM to let objects move around."

James Gosling on Jini
A few weeks later I had the opportunity to spend an hour on the phone with James Gosling, interviewing him for JavaOne Today, the online show daily produced by JavaWorld for Sun. I put the same question to him. Here's how that part of our interview went:

Bill Venners: I heard Java was originally envisioned for embedded devices. To what extent was Java designed with what would eventually come to be called Jini technology in mind? In other words, were you just thinking about embedded devices, or were you thinking about a Jini technology-like world?

James Gosling: Oddly enough, something very much like the Jini technology world was in there from day one. The very early version of the Java language, which was called Oak and ran on the Star Sevens, had a distributed message system in it that was very much like RMI.

Gosling offered more insights into his original vision for Java later in the interview when I asked him about the enterprise:

Bill Venners: To what extent did you envision the Java language playing a role in the enterprise when you first developed it?

James Gosling: It was a funny thing where very early on the view was that there was this established technology base that was pretty much impenetrable. Even though there were problems, market forces meant it was essentially impossible to break into the enterprise. So we decided to focus on areas where things weren't as tied up, which is partly where the consumer-electronics thing came in. We focused on that area because it seemed to be the most open one.

But when I designed the whole Java technology system, it came with years of experience doing all kinds of systems. And the reaction of enterprise folks, when they looked at the Java technology system, was, "Wow, this solves a whole bunch of my problems!" But early on getting into the enterprise certainly wasn't a goal.

Bill Venners: So given that it was more perceived along the lines of embedded devices, or that's how you thought of it, would you say there are deficiencies in Java for the enterprise environment, or areas in which you could do better at the language level?

James Gosling: I've done these embedded languages for a very long time. And one of the lessons that kept getting beaten into me over and over again is that when you design a system, you have some kind of a model of what people are going to do with it. And so you tend to build for that model. But every time I've done that, it's just been miserable, because people have always taken the system and done things that I never, ever expected. So when I designed the Java language, in many ways it was grotesquely overdesigned for its target.

Bill Venners: Is this the result of learning the hard way that people like to use things in ways you never imagined?

James Gosling: People always want to scale them up in amazing ways. And so I decided that this time around, rather than trying to focus on the particular application area, I was going to do a full-blown general-purpose thing.

Thus, when he originally designed Java, Gosling seemed to be imagining a world of embedded devices passing objects back and forth. Nevertheless, he tried to make the Java language as general-purpose as possible.

I found one more clue to the original vision of Java (and, subsequently, Jini) in Bill Joy's foreword to the Jini Specification book published by Addison Wesley. There, he writes:

For me, the Jini architecture represents the results of almost 20 years of yearning for a new substrate for distributed computing. Ever since I shipped the first widely used implementation of TCP/IP with the Berkeley Unix system, I have wanted to raise the level of discourse on the network from the bits and bytes of TCP/IP to the level of objects. Objects have the enormous advantage of combining the data with the code, greatly improving the reliability and integrity of systems. For me, the Jini architecture represents the culmination of this dream.

The extent to which Java was part of a master plan to make a Jini-like architecture possible (and the extent to which it was all a happy accident) is open to debate. But what is clear is that Java's architecture enables RMI and Jini, and that together, Java, RMI, and Jini mean that, as Jim Waldo put it during his talk last December in New York, "Object-oriented stuff is no longer limited to a single address space."

My sense is that extending the benefits of object-oriented programming beyond the borders of a single address space out into the network is the main point of Jini's architecture. For an explanation of how Jini brings object-orientation to the network, see the first Jiniology column.

Devices should 'be what they are'
A final glimpse into the vision for Jini that I'd like to share with you occurred during a conversation with Bill Joy at the Jini Community Summit's cocktail reception. It began when my Summit roommate, Torin Sarasas, asked Joy how Jini represents a "technology dislocation." Joy replied, "Jini is a dislocation in the context of cooperation of subspecies of devices. Once you have lots of different kinds of devices combining in different ways, you can't do monolithic software anymore. Each of these devices has a certain set of functions, and if we have to assume when we build them what they're going to be used for, it's not very [flexible]."

Joy then pulled out his cell phone and continued: "This is a cell phone. But it could also be a microphone. If I want to record this conversation, I just connect this microphone through the wireless to a recording service that stores it on a disk. And that's not something I had to preplan. Why should I have to carry around another microphone when I have this?" he asked, holding up his cell phone.

"When I get in the car, why should I have to install a speaker for a wireless phone when I already have one in the radio? I probably have nine speakers in there already and all these amplifiers, but I can't use them because they are locked into some integrated system."

It is interesting to note that the reason Bill Joy brought up the "recording this conversation" example may have been partly because Torin was doing just that, although I myself didn't realize it at the time. I was listening so intently to Joy describe Aspen's wireless network that I didn't even notice Torin dashing out the door. I later learned that when Joy first walked up to our group, Torin ran back to our hotel room at top speed (not easy at 9,000 feet) to collect his tape recorder. Thanks to Torin's athletics and recording device, I was able to write in detail about this portion of our conversation with Joy.

I felt Joy's comment about cooperation of subspecies of devices provided an important insight into the kind of flexibility Jini will offer when networks are ubiquitous. A cell phone is a device, but it is also a composition of many device subspecies, including a subspecies called a microphone. If Torin had brought a cell phone that offered a Jini microphone service, his microphone service could have cooperated with a recording service through the wireless network to record the conversation. Torin's mad dash back to the hotel room to retrieve his monolithic standalone recording device would have then been unnecessary.

Joy wrapped up this portion of our conversation by proposing a theory of devices. He said, "It argues for the devices to be what they are. Like what Frank Lloyd Wright's theory of architecture was: A brick should be a brick. A wall should be a wall. A column should be a column. And that invented a whole theory of architecture."

"The theory of a device would be: it is what it is." Holding up his cell phone again, Joy said, "This cell phone has a microphone. It has a numeric keypad. It has a display. It has a transmitter and receiver. That's what it is. It has a battery with a certain lifetime. It has a processor and some memory. If it's a European model it has a stored value card. It's a collection of things. It's some collection. The fact that its all one bundle, well, that's pretty artificial."

Conclusion
In this article I've tried to clarify why Jini exists and why it is designed the way it is. I think Jini's reason for existence is best summed up in Bill Joy's stack diagram shown in Figure 1. Jini is here to give an object-oriented interface to the computer of the future: federations of devices and services connected by a network. Jini's inventors didn't intend that Jini be the operating system for this emerging computer, but they did intend that Jini serve as its BIOS.

Discussion
To discuss the material presented in this article, visit: http://www.artima.com/jini/jf/vision/index.html

Next month
Although this column will in general focus on showing how to solve specific programming problems using Jini, such as how to add a GUI to a service or how to make a service administratable, next month I'm going discuss Jini's real-world problems and prospects.

Resources

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.

Copyright © 1996-2024 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use
Copyright © 1996-2024 Artima, Inc. All Rights Reserved.