Dennis Govoni
Sun Microsystems Computer Company

I have a dream. This dream is that in the future, any device that can be networked will be networked. I'm not talking about the usual suspects such as desktops, servers, routers, switches, and the like, I'm thinking about common everyday items we don't think of as being network-aware. I have a dream that someday our appliances, our houses, even our cars will participate in a network. The manufacturer of your car will be able to monitor its health and well-being, warn you if a problem is occurring, and even schedule maintenance. Our whole approach to network computing will change. The world will be more plug-and-play than it is now. We will view the network much as we do the phone system, with a "net tone" in place of a dial tone.        
        Network computing as it is today is too complex. For almost fifty years, we have been hamstrung by disk-oriented systems and software so complicated that it is virtually impossible to debug, and the problem is getting worse. Client-server computing, which promised to take advantage of the power in the desktop, has suffered in many cases from lack of understanding of the complexity of doing network computing, lack of tools, long development cycles, and deployment issues. Many companies have just not been prepared for dealing with administration of their networks and network-based software.
        But the current state of computing mandates the use of networks. Businesses and consumers are demanding more and more interaction with networks. It is not just that our reliance on networks is becoming a dependency, it is also that more and more devices are being integrated into these networks. Pagers, digital cameras, and the like already have network connectivity—and newer consumer devices are being built with an eye toward network connectivity. What I see is that more than half of future devices connected to a network will not be PC-centric. The devices of the future will require network connectivity, but they will also need to have a simple way to be managed and to be able to enter and leave the network in a seamless way. In essence, devices need to be simple yet capable of playing in a complex networked environment.        
        Recently, Bud Tribble of Sun Microsystems pointed out that as computer chips get cheaper, it is possible to put them in all sorts of devices. He further points out that the value of these devices increases as they become networked. Your automobile will contain networked components that will notify you of maintenance needs, even recalls. Microsoft is also working on this "Auto PC" approach (Haring, 1998).        
        Does this sound like science fiction to you? You may be surprised, but this technology is already here, albeit at an early stage. Four important drivers are bringing this to fruition:

  • The speed and number of different types of networks are increasing.
  • Systems are moving toward chip-level implementation, making them more reliable and very cheap. Thus it is cost-effective to put them literally everywhere.
  • Object technology is now reliable and easy to implement using Java.
  • We are becoming increasingly dependent on network connectivity.

        The demon that confronts this vision is that under the current technology, massive resources are needed to add, delete, and maintain a properly functioning network. As more and more services are offered on these networks, it becomes an administrative nightmare to manage and control them. The giant monolithic environments we all "enjoy" are a terrible fit for the networks of the future, which must be fluid and pliable to meet changing demands. Often components that fail or are improperly configured have dire effects on the running network. Complexity in these networks gives administrators indigestion. Something needs to change to simplify the building of these complex networks from relatively simple components.
         Just as the Internet is constantly changing, so will user requirements. We need a technology and methodology for allowing networks to be constructed on the fly with new services that will need to be reliable and constantly available. There will be a new generation of devices and services that will look outward—that is, they will be network-centric and capable of joining and leaving a network in a straightforward, seamless way (Joy, 1998) without disturbing the normal flow in the network.
        The vision that accompanies the preceding objective is that someday access to the Net will be by anyone, anywhere, anytime, on anything. The goal is to finally realize Marshall McLuhan's dream of "one huge computer" (Kelly and Reiss, 1998). While we now know that most computing devices such as PCs and workstations are the primary approaches to accessing the Internet, we can expect their usage rate will drop to around 50 percent as other devices become network-aware. As previously mentioned, we are already seeing phones, pagers, smartcards, kiosks, and even jewelry (Java™ Rings) being used as I/O devices to the Net. Much of this activity has happened in the last five years as the result of two inventions: Web-based technology and Java.        
        1993 was a turning point in the history of the Internet, with the invention of what is now known as the World Wide Web with the Mosaic browser, HTTP protocol, and HTML. People who never knew what network computing was all about were now enamored with "surfing the Net." The whole character of the Net and its use changed overnight. Once a research-only environment, the Internet is now a commercially oriented venture. But the Web interaction then was strictly of a static nature—that is, there was no way to deliver executable content that interacted with the user, much like a well-written program does. Therefore, it was necessary to find some technology that would mimic a human being's natural tendency to interact in a dynamic way. The first step in solving this problem was the invention of an Internet-aware language now known as Java.        
        In 1995, the Java language was born. The basic concept behind this language was to offer a platform-independent way to do computing on the Internet. Java provided a way to move executable content from the Web to the user, something the static nature of the World Wide Web did not previously provide. For the first time, applications (called applets) could be dynamically downloaded and executed in a user's browser. The user did not have to explicitly request the code or even reference a place to locate it. Network computing was now becoming powerful. Developers could concentrate on building network-aware applications without dealing with the complexity of the underlying infrastructure or using low-level network interfaces such as sockets and remote procedure calls (RPCs). Java became the lingua franca of the Internet. And Java was an object-oriented language, which meant that complex problems could be viewed as a simple set of objects. From this simplicity, complex solutions could be formed. All that was needed was a way to make Java-enabled devices and software transparent to the network.
        So while users now had a simple point-and-click approach to the Web via the browser, and developers had an elegant language that was "net aware" in Java, devices on the network that supported these technologies still required a significant level of expertise to configure and manage. Network computing was and is still too complicated. Something needed to be done to make the network more user-friendly—so services in the network could be viewed as simple objects that could be plugged in and immediately available to the network and its users, and so network services could be available on demand and could seamlessly enter and leave a network without disturbing it.
        And so, in the summer of 1998, Jini was born. In one sentence, Jini allows hardware and software to be automatically identified to a network and allows clients to easily locate and use these hardware and software services. To do this, Jini is totally Java-centric—that is, it relies on Java and the Java Virtual Machine.        
        Jini devices and software will enter a network automatically and become an integral part of a computing community using the underlying networks as its nervous system. There is no single point of failure in this community; as a device fails or leaves the network, the community "self-heals." Jini should be viewed as a system of services, not simply a bunch of devices and software. There is no concept of a single computer, but rather that of a set of services working in concert (Sun Microsystems, Inc., 1998). The network does, indeed, become the computer. But how does this actually work?
        In today's world, a similar function is fulfilled by providing access to devices that are connected directly to a computer—disk drives, scanners, multimedia devices, and the like. Jini allows these devices to be disassociated from the shackles of a computer system and tosses them out to the network. Physical location does not matter in a Jini environment. It simply exists on the network.        
        The immediate implications of this behavior are quite evident. First, it drastically limits the amount of configuration and administration needed. All the requisite code to interact with and properly access the device (or software, if it is a program) is inherent in the device or the software program.        
        Second, it means devices only need two connections: one for power and one for the network. Once the device is plugged into the network and powered up, it begins a process of identifying itself and what services it offers. With a software program, it would happen the same way. That is, once the program is started, it begins to identify itself and its services to the networking community. One interesting implication of this approach is the blurring of the distinction between hardware and software. From a user's perspective it really doesn't matter; users are only interested in using a service, not what the underlying implementation is. They leave that to the developer.        
        The method by which Jini devices and software join a network is quite straightforward. Once a Jini device is activated, it requests attention from a lookup service running on one or more servers. A lookup service provides a central repository where services can be registered and found. The beauty of this approach is that there can be many replicates of the lookup service in the network, thus providing redundancy and fault resilience. Once a Jini device has registered, it will pass any Java code that will be required by a client application of the lookup service to communicate with that device or program. So when a client enters the network, the first thing it will do is query the lookup service for a list of services that are available. Once it finds the service it wants, the code to interact with that device or program will automatically be downloaded. There will never be a need to preload device drivers or machine-specific code.        
        With code and data describing a device's capabilities able to move freely about the network as Java objects, all the basic ingredients for spontaneous networking are now available. Devices can interact with one another. For example, a camera may be ordered to take a picture and then send it to a specific printer. The camera would simply use the lookup service to find the printer and use the Java code the printer identified to the lookup service. No special driver code is needed by the camera to do this.        
        An analogous process is building a table. To build a table you need certain tools. When a hammer is needed, you simply retrieve one. When you are done, you no longer need it. Users obtain "tools" (Java code for devices) when they need them and not before. Every device has its own set of tools that a user will retrieve when the device is selected. The tools are provided in the device by the manufacturers of that device, since they are the designers. For example, printer manufacturers will provide Java objects for interacting with their printers and disk manufacturers will provide Java objects for their devices.        
        For network administrators, this method of providing "tools" means Jini devices can be easily added to and removed from the network without complex procedures and without a negative impact on the network. Management of devices becomes simpler because each device contains enough information to be self-managing; hence we have the notion of building a complexity of services via the simplicity of Java-oriented devices.        
        While Jini seems like an excellent answer for building complex networks from simple, object-oriented components, Jini devices still require the developer of that product to build the Java components that will allow clients to use it. The burden falls on the developer, not the users, but that is nothing new. Developers must provide the interfaces to their devices via Java code. So a printer manufacturer will need to provide Java methods for printing, error notification, resolution, and whatever else is needed to properly interact with their printer. With this approach, no one need install a printer driver from a disk or CD-ROM ever again. It can simply be obtained from the lookup service after the device has registered itself.        
        While this technology has the potential to be ubiquitous, what value does it have in the field of education? First, we should recognize that the use of networked-based computing is growing at all levels of education. Universities in particular want to reach more and more students in nontraditional ways. Use of the Internet and its technologies play a large part in these plans. The idea of a virtual university, venue independent, for students not able to physically be on campus has emerged at the University of Colorado, the Virtual Online University (aka Athena), and Washington State University, to name just a few.        
        Imagine Jini devices carried by students who will plug them into a network and instantly become part of a virtual classroom. Visual aids used in teaching can be easily added and removed by the instructor as needed. Even coursework can be objectified such that it becomes "Jini-aware" and part of a virtual classroom. One example might be a music appreciation class. The music CDs would be loaded into a Jini-enabled CD player, which would then identify the selections to the network. Jini-enabled software would monitor where each student is in the course and what selections he or she has used. In this way, the content of the course could be more tuned to each student's particular needs. While this could also be done with other current technology, Jini makes it easier to develop network-aware educational experiences, which can be plugged into the network and become immediately available. No special administration of a Web site is needed; information just shows up in the lookup service.        
        As a result of Jini, we can expect development of a more dynamic educational experience for students and the means to allow students access to that experience anytime, anywhere by plugging their client devices into the network. What will these client devices be? Well, they can be anything that will interact with the Jini device. In our music example, they might be Jini-enabled headphones that would identify each student with a simple input device for accessing the selections on the CD player that he or she needs to hear. For chemistry or biology students, they might be devices for monitoring the status of experiments in a lab across campus from the dormitories.        
        One very simple but powerful way Jini could be used is in mobile computing, where students could read their mail by simply plugging into the network and being instantly identified. (This technology could also be wireless.) The client device could be a Jini pager or display phone or PDA. The concept behind all of this is "spontaneous networking," gaining access anywhere, anytime, on anything.        
        Why should Jini matter to you? Think of how much networking and administrative costs have risen in recent years and how much duplication of effort there is, particularly in client-side software. Jini may also help reduce costs by avoiding the problem of obsolescence of equipment. How? As an example, a 486 PC could be used to access Jini services without that PC needing 40 million lines of code on it to use the network and services. It would need only to have a Java environment with a Jini client code that could use the power of the Jini devices on the network. This approach should help to greatly reduce the cost and complexity of maintaining a distributed computing environment that is only getting more complex.        
        We are, of course, at the beginning of this journey; the landscape for Jini will emerge over the next few years. Suffice it to say that some thirty large corporations are already building Jini devices, which we will see in the near future. Jini software requires only the imagination of the developer to implement it. I expect to see many innovative solutions not only in the corporate world, but also in the educational arena, where many new ideas are spawned. Jini proves not only that "the network is the computer," but that the network is whatever is on it.


Haring, B. "Coming Soon: Cooperating Appliances." USA Today Tech Extra, Oct. 7, 1998, p. 5D.

Joy, B. "Jini Keynote Address." Internet Week, Fall 1998.

Kelly, K., and Reiss, S. "One Huge Computer." Wired, Aug. 1998, p. 122.

Sun Microsystems, Inc. "Why Jini Technology Now?" Sun White Paper, Revision 1.0. http://www.sun.com/jini/whitepapers/whyjininow.html. Aug. 1998.

All material within the HORIZON site, unless otherwise noted, may be distributed freely for educational purposes. If you do redistribute any of this material, it must retain this copyright notice and you must use appropriate citation including the URL. Also, we would appreciate your sending James L. Morrison a note as to how you are using it. HTML and design by Noel Fiser, ©2006. Page last modified: 7/8/1999 10:45:21 AM. 20498 visitors since February 2000.