Java's secret weapon

Revisiting the Jini vision

A recent New York Times article ("Unfazed by Defectors, Sun's Chief Charts Next Era," John Markoff (May 3, 2002)) asked Sun Microsystems Chairman and CEO Scott McNealy about the company's plans to increase its software offerings' prominence. Sun has lately reorganized its software operations under one umbrella, which now includes its Java division. Far from becoming a pure software company, said McNealy, Sun's strategy is to sell "metal-wrapped or plastic-wrapped software"—software and hardware combinations that together present a more attractive solution than one would without the other.

Sun's business strategy should worry any Java developer: Sun is the only major technology company entirely dedicated to the Java platform. While firms such as IBM, HP, Oracle, or Motorola, have significantly contributed to the Java platform, they all have other chestnuts in the fire. With Microsoft's promotion of the .Net framework—in effect, a paraphrase of key Java features—Sun's successful execution of its strategy holds increasing importance for Java's long-term future. In this article, I focus on how Sun leverages Jini, and why Jini might be a secret weapon in ensuring Java's viability in the coming years.

At the heart of Sun's announcement lies a desire to forge closer ties between its hardware and software offerings. In other words, Sun portends to offer, as Sun Fellow and Chief Engineer Rob Gingell says, "systems of computing." Those systems, in turn, might be realized either in hardware or software, or both. The distinction between hardware and software becomes an implementation issue and might not even be visible to system users. (Gingell discusses systems of computing and more in "Jini's Relevance Emerges, Part 1.")

In one of the first articles describing Jini in 1998, Jim Waldo, Jini's chief architect, remarked: "One of the keys behind the Jini system is that we have tried to erase the distinction between hardware and software." If Sun is to create a more coherent offering of systems of computing, Jini, a technology originated at Sun, should play a crucial role in that process.

However, Sun has received much criticism recently from Java developers over its seeming lack of support for Jini. The 2002 JavaOne Conference, while featuring numerous Jini-related sessions, gave center stage to XML-based Web services. Informal conversations during JavaOne revealed that seasoned Java programmers view Sun's promotion of XML-based Web services as a setback. These developers believe that, while XML has a place in Java, Jini accomplishes the software-as-services vision much better. Some claim that Sun is admitting that Jini failed to catch on in the marketplace and is back-pedaling on the original Jini vision.

Sun cofounder Bill Joy expounded that vision in his presentation at the first Jini Community Summit in Aspen, Colorado in May 1999. Bill Venners summarized part of Joy's speech in "The Jini Vision," (JavaWorld, August 1999): 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 email are 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."

During his speech, Joy echoed earlier visions of the "invisible computer," or ubiquitous computing, a term coined in the late 1980s by Mark Weiser, then head of Xerox's Palo Alto Research Center (PARC). Ubiquitous computing places information in the center of our computing world, in contrast to the devices that let us access that information. Computers in that world are embedded everywhere. Receding into the background, they make us unaware of their presence, allowing seamless interaction between the machine world and the human world. (See Resources for more on ubiquitous computing).

Indeed, the original Jini vision touched on the core of the computer's meaning. During that same Jini community meeting, Waldo noted that we have traditionally thought of computers as devices having "a CPU, some memory, and a disk. Since disk drives keep getting bigger...we put all our software on the [local] disk." That traditional, local disk-centric approach points to much of our current software architectures. To quote from Venners' article:

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

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

Remove local storage, and those assumptions no longer hold. Removing local storage does not remove the storage device; instead, the storage device might no longer serve as the sole repository of code and data needed to operate the computer. Anyone owning a cell phone has already experienced that phenomenon. As Waldo noted at the Aspen meeting, "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." In a communication-oriented device, software codes, including the device's configuration, can partially arrive via the network.

The Jini vision does not aim to alter a computer's basic building blocks, such as storage devices or CPUs. Rather, it defines a new relationship between those ingredients: instead of close coupling, it prescribes a loose federation. Jini, however, does introduce a new component to the computer: the network. The network, connecting a computer's pieces together, becomes the "system bus," and thus, an integral part of the machine itself. While that means every network-connected component can now become part of the computer, the network also introduces a set of new requirements that the software operating that computer must follow.

During that first Jini Community Summit, Joy highlighted how Jini supports those new requirements. Quoting Venners' article again:

[Joy] showed several "stacks" that represented various stages in the evolution of the computing model. The last stack...represented the computing model that Joy claims is now emerging. It was labeled "object-centric." 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 [remote method invocation], 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.

In other words, Jini helps satisfy the requirements introduced by the insertion of the network into the computation—by representing devices and services as objects, and sending those objects across the network. Using Jini as a BIOS for this new computer, you can create higher-layer software—software that lives on the network and leverages all the network's resources.

By the 2001 JavaOne Conference, a growing sense of disillusionment had set in the Jini community. The root of that frustration: Jini-enabled software hadn't materialized. At the 2001 Jini Jam in San Francisco, Jini community members blamed Jini's lacking popularity on Sun's hesitant marketing of Jini. Since Sun was promoting J2EE (Java 2 Platform, Enterprise Edition) as the solution of choice to its largest customers, Jini had little chance of taking root inside enterprises and proving itself as a serious platform on which to build large-scale enterprise applications. Enterprise applications remain the major revenue source for software developers. Relegating that market to J2EE leaves Jini enthusiasts with few incentives to build businesses around Jini. A year later, in 2002, J2EE is no longer the sole perceived threat to Jini; Sun's support of XML-based Web services promises yet another non-Jini alternative for enterprise-style computing.

Paul LaCrosse, president of the LaCrosse Consulting Company, who works with one of the world's largest auto manufacturers on a Jini project, laments: "Our management was, and remains, skeptical of Jini mainly because we don't read about it any more in the industry magazines. Our group definitely felt the sting of abandonment. We hope that Sun is planning an all-out promotion of Jini once the Davis release [the next version of Sun's Jini Starter Kit, scheduled for release in 2003] is made."

Adds Judith Arato, former head of business development at PsiNaptic, a Canadian company that offers a small-footprint Jini implementation: "A few years back, Java did not have a clear roadmap. Developers didn't know where Jini fit in the end-to-end solution space that ranges from J2ME [Java 2 Platform, Micro Edition] to J2EE. The original message that 'Jini is for devices' was attractive, but when companies tried to actually use Jini, Jini didn't fit into the small [virtual machine] space available on those devices. Many said, 'Great technology, what the heck do we do with it?'"

Some in the Jini community began to succumb to pessimism about Jini's future. A typical example is a recent JavaPro article "Whatever Happened to Jini?" by Daniel Savarese (August 2002) who contrasts Jini's apparent slow progress to the—apparently—rapid interest in XML-based Web services:

Jini is, in a sense, a closed system. It assumes an all-Java environment even though some extensions, such as the surrogate architecture...have been added for tying in non-Java elements. If I were forced to hypothesize one reason for Jini's lack of popularity, it would be, strangely enough, its Java-centric nature...The growing presence of J2ME [Java 2 Platform, Micro Edition] and HTTP on small mobile devices coupled with the steadily increasing popularity of Web services lead me to believe that Jini will become irrelevant...In effect, XML is the answer, not Java. At least it is the answer chosen by users...Rather than make the communication system the locus of commonality, Jini makes the computational system, Java, the locus. I will bet that the Jxta peer-to-peer project...which defines platform-neutral communication protocols, will eclipse Jini as a vehicle for distributed computing, simply on that account, as Web services already have.

What did happen to Jini?

While doom and gloom accompany the development of many a technology, most in the Jini community have succeeded with Jini. Without much fanfare, Jini community members started to ship Jini-based products, even for enterprise use, and several open source projects have sprung up.

And since 1999, the Jini community itself has grown. According to Jim Hurley, senior engineering manager on Sun's Jini team and Sun's chief Jini community liaison, more than 95,000 developers have signed the Sun Community Source License, or SCSL, and downloaded the Jini Starter Kit—Sun's implementation of the Jini specifications. Those developers serious about Jini development create an account at "We currently maintain about 24,000 such accounts," says Hurley.

In June 2002, Sun arranged to host the Jini community Website with CollabNet, whose collaborative software development tools are well known among open source and community source programmers. By comparison to's 24,000 user accounts, Project Jxta's Website indicated it had 10,515 developer accounts (as of August 6, 2002). Apart from, the main technical communication medium among Jini community members is the Jini-users mailing list, which, according to Hurley, boasts about 1,900 subscribers. The mailing list is active, with 436 messages exchanged in July alone.

Lately, Sun has been making Jini increasingly accessible to developers. When it introduced Jini under the SCSL, it received resistance from the developer community. Many developers and potential Jini users would have preferred an open source license for Jini such as a BSD (Berkeley Software Distribution)-style license model or the Apache license. That initial resistance was not surprising, considering that Sun used Jini as a test bed for the SCSL.

According to Sonali Shah, a doctoral candidate at MIT's Sloan School of Management, and a specialist on open source communities, once developers and users become familiar with the SCSL, they often prefer it to open source license models, such as the GNU General Public License (GPL). Sun's SCSL shares features with the BSD license, which originated at the University of California, Berkeley, where it served as the main distribution model for that university's version of the Unix operating system.

1 2 3 Page 1
Page 1 of 3