Sun Dreams of Jini

Dr. Dobb's Journal November 1998

By Michael Swaine

Michael is editor-at-large for DDJ. He can be contacted at mswaine@swaine.com.
Sidebar: Paradigms Past: The End of the Brotherhood

Although next month I expect to be all over the paradigmatic map with my annual stocking stuffers column, this month I'm focusing on a single paradigm.

It's Sun's Jini, a new system architecture for distributed computing and improved device connection. I think that's an accurate description, but it certainly doesn't do Jini justice. Jini is so revolutionary a technology that it has appeared on the cover of Wired magazine. Oh, sorry. I forgot to turn on my cynicism filter. And I do need to hold my cynicism in abeyance, even though Jini is a Sun technology and starts with the letter j and is therefore fated to be hyped to the heavens. Because technologically speaking, Jini is clearly important, clever, impressive, and worthy of serious attention.

Of course technological merit is seldom the deciding factor in the success or failure of technologies in certain strata of software development...

The Vision

Jini is part of a four-year research project carried on at Bill Joy's Sun Aspen Smallworks R&D lab in the Rockies. Java was also a part of that project, but only a part. The release of information on Jini this summer is the sound of the other shoe dropping. Jini expands on the Write Once, Run Anywhere concept of Java and articulates a more ambitious and more complete vision for the future of computing. One element of that vision is a radical simplification of the way hardware is connected and configured. In the Jini model, every device -- computer, disk drive, telephone, camera, or coffeepot -- has just two cords coming out the back -- one for power and another for the network. (Or just one: The network cord might be replaced by a wireless link.) You plug it in, it announces itself to the network, and it's all connected and configured and jumpered and registered and immediately usable.

Sounds nifty, but talk is cheap and hardware is expensive. Wouldn't such a scheme require all new hardware? Yes, although it would be possible for the smarts that let the device be a player in a Jini system to reside on another device. In this way, old devices could join a Jini system.

Another element of the vision is a model for distributed computing. It's also an ambitious model -- in a way. In the Jini model, anything can be a service, available to clients on the network. A service might be the printing capability of a printer somewhere on the network, or a math routine, or a search engine, or a slice of processing power of a mainframe made available to underpowered PCs doing heavy but decomposable computations.

In another sense, the Jini model is very modest. The core software is 48 KB of binaries. And it is intended to run on top of any OS (although currently has been implemented only for Solaris and NT).

On the less modest hand, while living in apparent harmony with any operating system, it quietly usurps all the interesting networking functions. And it attempts to promote the network to a level of importance and control currently occupied by the operating system. In this respect, Jini is clearly another Sun attempt to do a technological end run around Microsoft's hegemony.

Maybe we could call it Sun's version of "Embrace and extend." Anyway, that's the vision. Oh, and Joy's boys want you to be able to walk up to any device, not just any computer but any device connected to a Jini system, and have all of the system's services as available to you as they would be if you were sitting in front of your own PC; and they want all this to be so automatic and transparent to the user that it is in effect a network dialtone.

Sure, why not. All this sounds like network heaven, but is there any reason to believe that Sun has the keys to the kingdom? That's the 64-euro question, of course. I'll just spell out some of the details of the Jini model and you can decide that for yourself.

Joining Jini

Jini embodies a model for how devices and software connect on a network and how distributed systems can operate. Sun describes the technology underlying this model in terms of two areas of software -- the infrastructure that defines the connections, and the distributed programming model.

In addition to these, there is the concept of a network service, a concept that runs throughout the entire Jini model.

A service is, according to Sun's Jini Architecture Overview white paper (http:// java.sun.com/products/jini/whitepapers/ architectureoverview.pdf), "an entity that can be used by a person, a program, or another service." It can be "a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user."

The infrastructure consists of two components that, between them, make it possible for devices to be hot-plugged into the network, manage the process of devices identifying themselves to the network and vice-versa, and allow clients to access services anywhere on the network. These are "Discovery and Join" (that's one component with two names) and "Lookup" (also referred to as "Boot and Join" and "Install"). Discovery and Join is the mechanism by which a device or application identifies itself to the network. When a Jini-enabled device is plugged into a Jini-enabled network, the device broadcasts a small Discovery packet to the net. This 512-byte packet contains sufficient information to allow the net to start a dialog with the device, which it does, on encountering the packet on a known port, by sending the device a packet that describes the network's characteristics. (The device doesn't need to know anything about the network in advance.) That's Discovery. Now the device can Join the network, which it does by sending a more comprehensive message back, containing all its own characteristics (I print in color, I respond to the following voice commands, I chop small vegetables). This message can contain more than just device characteristics: it can also include code or code pointers, as for example a printer driver, an interface to a printer driver, or a help wizard. The medium of communication here is a Java interface. Jini is perfectly willing to work with C code at some levels, but here it's built firmly on Java.

Lookup is the component that does what I have loosely attributed to the net in previous paragraphs. It is a small bulletin board for the net, dynamically storing pointers to services, and also code or pointers to code provided by services. Clients for these services talk to Lookup to get, for example, the driver for a printer downloaded when needed. Lookup is the main point of contact between the system and its users. What it does is to map Java interfaces that identify offered functionality to a set of objects that provide that functionality (that is, that service).

A twist on this Lookup capability is Peer Lookup, in which a client can masquerade as a Lookup if no Lookup is available. The client itself then engages in the Discovery and Join conversation with the service providers, who register with the client just as if it were a Lookup.

Beyond Java

The distributed programming model in Jini brings three technologies to the picture -- leasing, distributed transactions, and distributed events. In leasing, an object negotiates for the use of a service for a period of time. This is the basis for, among other things, the system's distributed garbage collection. Leases can be exclusive or nonexclusive, nonexclusive leases allowing for simultaneous resource sharing. Java APIs provide the basic distributed transaction capability, called "two-phase commit." This allows an object to fire up a transaction manager. Every object that will take part in the transaction has to register with the transaction manager, and it runs the transaction, holding up objects or causing them to backtrack or move ahead as needed to ensure that the steps of the transaction are properly synchronized. Jini also provides for distributed events. Specifically, an object can allow other objects to register an interest in an event that resides in the first object, and provide notification to them of the occurrence of the event.

Underlying all communication between services in Jini is Java Remote Method Invocation (RMI). Although it might seem more like part of the programming model, it is regarded as part of the infrastructure. Wherever it falls in the architecture of Jini, its role is to allow complete objects, including code, to be passed among objects over the network.

Network services is an open-ended collection of services that bear somewhat the same relationship to the infrastructure and distributed programming model as applications do to an operating system, running on top of these lower-level elements.

The most important of these is JavaSpaces, a model for facilitating distributed programming. The JavaSpaces model is drawn from work by David Gelernter that simplifies the challenge of distributing tasks among multiple processors. Gelernter's project, named Linda, creates a shared memory space called a TupleSpace where results of a computer's processes or the processes themselves are stored and can be accessed by multiple CPUs. Contents of a TupleSpace are tagged with self-descriptive tags, and effectively push-pinned to a bulletin board.

Jini is Not a Dictatorship

Jim Waldo, author of the Jini Architecture Overview white paper, characterizes a Jini system as a federation. Members of a federation are peers and are assumed to agree on certain basic issues. Trust, identification, policy, things like that.

"A Jini federation should not be thought of as sets of clients and servers, or users and programs, or even programs and files," Waldo says. Instead, you should think of it as an open-ended, dynamically changing collection of independent services that can be composed together to perform a task.

Services communicate with one another via a service protocol, which is a Java interface. There can be any number of such protocols; they are, like the services, an open-ended collection.

Security in Jini follows a provider/access control list model. The principal is whomever or whatever the service is accessed for -- ultimately it will probably be some user somewhere, but the immediate principal may be another object. The access control list is associated with and controlled by the object that implements the service. In short, the owner of the service gets to decide who does what with it when. Jini is designed to be decoupleable, so that it is possible to implement parts of the system and still get many of its benefits. I haven't dug deeply enough to know what parts and what benefits, but the idea is to allow legacy code to play a (perhaps limited) role in a Jini federation with only minor modification.

That legacy code would probably be C code. Jini itself is built on Java, though, and Java underlies all the components of Jini. When you lump in that Java infra-infrastructure, those components look like Table 1.

What it Means

This is a powerful vision, but it doesn't add up to a product that Sun can sell in shrinkwrapped form to consumers with a marketing blitz featuring Larry Hagman and Barbara Eden. Jini is really an appeal to the industry to join Sun in forming a federation of companies that all buy into Bill Joy's dream. Hardware companies will have to rework their equipment, and software companies will have to rework their minds if they are to buy into this thing.

But some companies have, to one extent or another, bought into the Jini vision, including Canon, Computer Associates, Epson, Ericsson, FedEx, Mitsubishi, Novell, Oki, Salomon Brothers, Seagate, Siemens, and Toshiba. Sun says that the source code will be open as in the Mozilla model and that they will enforce compatibility in some way, probably through an authorized label for Sun-certified compatible commercial products.

It would be easy to dismiss the Jini effort as a dream that has very little chance of coming to reality. Microsoft isn't about to endorse it, can in fact be counted on to embrace it about the same way they embraced Java. And other companies are being asked, at minimum, to make an investment in an unproven technology, and at max, to rethink their entire business and software development models.

Against that imposing challenge, there is this small thought: Something like this is going to happen someday. Why not now? And why not from the guy who has been thinking about it for all his adult life, Mr. "The network is the computer" himself? It's Bill Joy's dream. And it might come true.

DDJ


Copyright © 1998, Dr. Dobb's Journal