Pacific Connection(英語)

Sun's Jini Hopes to Redefine "Plug and Play"

In 1890, the Rocky Mountain town of Aspen, Colorado was best known for silver mining--the largest single producer in the United. States. In 1947, what was then the world's largest ski lift began taking skiers up Aspen Mountain. Today, winter skiing, summer film and music festivals are what most people think of when they think of Aspen.

But probably not Bill Gates. For Aspen is also home to that industry legend and Microsoft annoyance, Bill Joy, as well as small team of researchers who keep cranking out ideas with the potential to radically alter the Windows-dominated technology hierarchy. Joy, of course, already has a formidable reputation as the godfather of Berkeley UNIX, the co-founder of Sun Microsystems, and one of the principal architects of the Java programming environment. Since 1994, Joy's Aspen-based Smallworks R&D lab has been quietly developing what might be considered the next logical step for Java: Jini.

Jini (pronounced "Genie" like the spirit living in Aladdin's lamp) is a proposed networking infrastructure running on top of Java. The initial specification is now on the Sun website. Jini's promise is ambitious: a network that can support not just servers, workstations and printers, but digital cameras, video tape recorders, and the rest of the vast menagerie loosely known as appliances. Mike Clary, director of the Jini project, envisions that almost any class of device is a potential client: portable computers, printers, scanners, disk drives, DVD and CD players, phones, VCRs, TVs, alarm systems, heart monitors, heating and air-conditioning systems, automobile engine and dashboard computers, and kitchen appliances.

Strictly speaking, Bill Joy didn't so much write Jini as inspire and conceive of it. The man behind the nuts and bolts of the technology is Jim Waldo, assisted by Sun stars Ann Wollrath, who invented the Java Remote Method Invocation (Java RMI); and Ken Arnold, a designer of JavaSpaces services and a co-author of the Java programming language. Their idea is that plugging a client into a network should be as simple as plugging a lamp into a socket. The user shouldn't have to worry about device drivers or toggle switches or restarting the system. When you plug a device into a Jini system, the system "knows" what that appliance is capable of and what its requirements are. There is no need to take the network down, no need to reboot. User's don't have to worry about software drivers or toggle switches. By design, Jini is the local area network we all thought we had in the first place.

In addition to the network ideal in which any device can be plugged in anywhere, at any time, without fuss, Jini will also provide conventional distributed processing, albeit with unconventional devices. Mike Clary envisions a network in which computers "rent" their processors out to other computers. Nor surprisingly, Sun has gotten strong interest from peripheral manufacturers, who see an opportunity to become value-added service providers. Quantum, for example, could develop standalone drives that attach directly to a Jini network, providing storage solutions, rather than being embedded within a traditional file server.

Jini is a natural outgrowth of Java research--a means to extend the platform-independence of Java to distributed computing. And while nobody is promising a working commercial Jini network any time soon, Sun already has some 30 partners on board, including Epson, Novell, Quantum, Seagate, and Siemens. Toshiba is developing a Jini-based prototype and wants to propose extensions to the Jini specification. Mitsubishi views Jini as a new infrastructure for its networked consumer and industrial devices, and sees potential applications in home electronics, communication systems and automation management.

"We don't really know exactly where we are going, but we understand that significant technologies like this one don't come along very often," said Billy Moon, director of new concepts at Ericsson, in an interview with the San Jose Mercury News. "I see this as a majorly significant technical event." To license Jini, Sun has followed Netscape and Mozilla in adopting the open source code model. The company hopes to have the open source available on its website in the fourth quarter of 1998.

It's important to note that Jini describes the protocol for exchanging information, not the physical network itself. But assumptions about physical network throughput are modest--10 Mbps in most cases--although higher bandwidth may be needed, depending on the devices. Jini also makes few assumptions about the physical architecture of the clients. It assumes that each client has some memory and processing power or are controlled by a device that does. Moreover, while Jini is based on the Java application environment, it does not require the Java Programming Language. Jini will support an application developed in any language if a compiler is available to produce bytecodes for the Java language.

Spontaneous networking

Jini provides what Sun calls "spontaneous networking," that is, the ability to exchange services between any hardware or software on the network without configuration, installation of new drivers, or network rebooting. On a Jini system, devices sign on by identifying who they are, what services they need, and what services they offer. Hence a camera might identify itself as such and ask, in effect, if "anyone needs any pictures?" The camera might also be interested in the presence of a network printer in which to output hardcopy output, and a network disk drive might also get involved as a repository for JPEG files.

If this sounds like a "community" of devices, that's how Sun envisions it. Sun says that the Jini architecture "federates" groups of devices and software components into a single, dynamic distributed system. Indeed, the company has purposely not used the word "network," preferring instead to call Jini a "system."

Sun refers to a "federation" of Java virtual machines, representing devices, applications, data-and even people. A federation is defined by the citizens who join it, much the way a "birds of a feather" discussion can arise almost spontaneously by human beings at a conference. Jini citizens contact each other, not through a driver, but by exchanging chunks of Java code-either through a central lookup facility in a defined federation or in a peer-to-peer basis. This community can share work without prior knowledge of each other, and Jini citizens can join one or more federations by announcing themselves and offering their services.

If signing on to a Jini system centers around the exchange of services, exactly what constitutes a "service" is fairly broad. Sun defines it as anything that can be used by a person, a program or another service. "A service may be a computation, storage, a communications channel to another user, a software filter, a hardware device, or another user," writes Jim Waldo in the Jini Architecture Overview. "A service may be more specific than this, for example, providing a translation from one word processor format to another or translating a document from one language to another." In Jini-speak, clients join a Jini system to "federate in order to share access to services." Indeed, the very definition of a Jini federation is not a set users or programs and files, but a set of services that are collectively available for a particular task. As for the size of a Jini system, it can vary greatly, from a couple of users on up to 1,000. More clients can be accommodated by federating Jini systems. By design, Jini is large enough to handle the needs of a single workgroup: in an office, or dispersed using wireless connections.

At the same time, simplicity has been a design goal since the beginning. In keeping with a philosophy of "less is more," it will take just 48K of Java software binaries to access a device within a Jini system. As Waldo put it: "We stopped only when we couldn't throw out anything else."

This theme is echoed by Sun executives like Joy and Scott McNealy, who have been openly critical of the current approach to designing system software, calling the code way too complex for what it is trying to accomplish. Joy has likened some C and C++ applications to "beached whales"--programs so big that they can't get into the water. Nor has he spared Sun itself in complaining that Solaris, Sun's version of Unix, is built out of materials that are very difficult to work with. As for Windows NT 4.0, the OS "is 16.5 million lines of code that will never be debugged," Joy said in a recent Wired interview. "It is like having an elephant living in your apartment. The thing is just monstrous. NT for consumers is an oxymoron because NT is basically mainframe software with all these windows and very little architecture....Many people were happy with the cars they bought from Detroit before Honda came along. I'd like to think that Java is more like when the Japanese came along with quality cars. With Java-based programming, instead of having one big system with infinitely complex buggy software, we can get a federation of machines working together to solve problems. The individual components are simpler."

Discover and join

Sun calls the mechanism for enabling a device to log onto a Jini system and offer its services "discover and join." The process starts as soon as a client is plugged in. That initiates a 512-byte "discovery packet," which is intercepted by a key component of Jini, called the Jini lookup service. This service--and there can be more than one on a Jini system--functions as a bulletin board, tracking all services on the network. Just as a community bulletin board in a small U.S. town might help people rent rooms, sell cars, and offer gardening services, the Jini lookup service acts as a registry of available client services, and thus a central reference site for services that need to get done.

When a lookup service receives a discovery packet, it uses the device's interface to link the device to the network. The device or application is now said to have "discovered the network." The next step is for a "proxy" of the service to be loaded into the lookup service. The proxy contains the interface for the service, as well as any attributes of that service--which are used by clients to locate what they need. When a client finds what it is looking for, it loads the proxy code, which acts on the client's behalf in obtaining the service. Waldo points out that this approach of registering a proxy in a central location and passing it to a client has some advantages. Because the service itself provides the proxy, the proxy is by definition the right one for the service. And the proxy code can contain proprietary technology known only to the developer of the service. It can act on behalf of the service, without having to explain itself to the client.

Because of the wide range of devices supported, the service attributes a device posts to the lookup service vary considerably. For example, a printer might show whether it can produce color, support PostScript, and do speed printing. A digital camera might indicate how many megapixels it is capable of storing. A disk drive might indicate available storage capacity and throughput.

The Jini architecture also allows for cases in which information may not be available on the lookup service. Instead, a client can work on a peer-to-peer basis by using the same discover and join packet, but issuing it to any service providers "listening" on the network. Jini also has a facility called Leasing, which determines how long a service will be available. Under Leasing, when a device requests a service, it also negotiates a time that will need that service. If more time is needed, the "contract" must be renegotiated. The Jini system handles distributed events through a Java API facility, which ensures that events do not get lost and that the sequence number is not out of order. Similarly, Jini provides a simple Java API that manages transactions to insure that all events occur before the entire transaction is committed. This process, similar to what goes on in a database, can roll back a transaction to the last known state, or, if all parts of the transaction are completed, it can roll the transaction forward.

Services communicate with each other using Java Remote Method Invocation (RMI). RMI works similarly to a remote procedure call, but can pass not only data from one object to another, but entire objects, including the code. "Much of the simplicity of the Jini system is enabled by this ability to move code around the network in a form that is encapsulated by an object," writes Waldo.

Developer Rawn Shah notes in a Java World article that the story behind the Jini network is actually two technologies: Jini and JavaSpaces. Jini's services include lookups, registration and leasing, while JavaSpaces manages object processing, sharing, and migration. "By itself, Jini works to create a sort of "plug-and-play" environment for all sorts of devices and software components on a network. JavaSpaces uses this architecture to create distributed computing systems." For Shah, JavaSpaces is the ultimate promise of Jini, and Jini makes JavaSpaces possible.

The JavaSpaces concept is both simple and useful. Clients look for services on a JavaSpaces server-issuing a "template" that describes a certain type of object. The server responds with the object entry that best fits the description. The client can then copy the entry, take it (so that it is unavailable to other clients), write it back so that it is again available, and notify the server that it is looking for a particular entry.

JavaSpaces is "a very simple concept in theory, but one that involves many services to handle the different parts," writes Shah. "For example, each read, write, or take operation is a transaction and can be undone, so security is an issue. It's important to confirm that request clients have proper access rights to the entries. In addition, a mechanism needs to be in place to notify the different clients registered using the notify operation, and you need to be sure one client doesn't hog entries for itself. And guess what? Jini does it all."

What's interesting about JavaSpaces, and, for that matter, JavaBeans and JavaServer, is how much Java infrastructure Sun has managed to build from Java itself. Many have questioned how Sun can make money on a technology that it gives away almost free-of-charge. The same might be asked of Jini, whose progress, as noted above, will follow the open source model. As Sun doesn't break down its revenues by products, that question is hard to answer. But clearly, the company did not just rely on one Bill Joy inspiration and sit back. Sun keeps weaving new technologies out of Joy's original inspiration-first with Java, a development environment that threatens to overturn C and C++, and now with a distributed environment that could do the same for conventional networks. If Sun and its Smallworks lab haven't yet changed the world, they are coming ever closer.

Bill Joy and Aspen Chic

Aspen Colorado is home both to Sun's Bill Joy and the crazed journalist Hunter Thompson: two men with enough clout to work wherever they like. Joy has achieved such god-like status, let alone wealth, that he can pursue any project he chooses while living and working in an area that other Americans are lucky to visit.

Joy exemplifies an axiom of the California's computer industry: the ultimate Silicon Valley status symbol is not a BMW or an Armani suit, but the freedom to do what you like. At one Sun presentation, for example, you could tell the ranking of engineers by how they dressed. The junior members wore neat slacks and matching shirts with collars. They looked like they were ready for the golf course. The more senior members looked a bit scruffier; some golf courses might not let them play. As for Bill Joy, he wore jeans and cowboy boots and looked as if he just stepped off the ranch. The assembled audience of journalists and customers had no doubt who was the ranking member.