Recent top five:
Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first
post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together
in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...
Featured Whitepapers
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
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):
...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 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:
- 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
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?'"
