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:

  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 http://www.jini.org. "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 Jini.org's 24,000 user accounts, Project Jxta's Website indicated it had 10,515 developer accounts (as of August 6, 2002). Apart from Jini.org, 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.

Page 2 of 3

"The BSD and SCSL can be mixed with a proprietary license, whereas the GPL cannot," says Shah. "All three licenses provide a way for you, the developer, to redistribute your binaries as well as source code." She explains that the SCSL is a gated license, where you can distribute source code only to those who have signed the SCSL. With a BSD license, if you're building on someone else's work, you're not required to share your contributions. However, the GPL says you must share your contributions with everyone and publish your modifications. Also, if your code contains something licensed under GPL, that code is now licensed under GPL. "Obviously, a firm or consultant might not like this restriction," continues Shah.

Though the SCSL stipulates the sharing of intellectual property contributions with all developers, in contrast to the GPL, you must share only certain types of work, such as bug fixes, APIs, and compatibility requirements. SCSL also gives the original developer—Sun—a few special rights.

Currently, Sun licenses the JDK under the SCSL license as well. In October 2000, the company simplified the SCSL's text, mainly to make its terms easier to understand by the developer community. At the same time, Sun also eliminated any licensing fee associated with Jini: Jini has since been free.

JiniFest

These changes seem to have encouraged momentum in the Jini community. Nowhere was Jini's success more evident than at JiniFest, the Jini community's first product and technology showcase. Sponsored by Sun's Jini group, but organized by Jini community volunteers, the evening-long affair took place in San Francisco in March 2002, during JavaOne. JiniFest assembled roughly two-dozen Jini-related projects and companies, exhibiting wares to the more than 300 guests that filed through the showroom.

As a JiniFest organizer, I was surprised by the strong grassroots support for Jini among Java developers. The Jini vision was alive and well, but most developers were unsure how that vision would reach fulfillment. The enthusiasm about Jini contrasted to the general developer attitude towards Web services, JavaOne's main topic this year. Many developers admitted that Sun's support for XML-based Web services was a pragmatic necessity, but noted that Web services just lack Jini's cool factor.

Since developers have no clear Jini roadmap, many hesitate to jump on the Jini bandwagon and prefer instead to observe it from the sidelines. The absence of a clear Jini roadmap is due to the way in which the Jini vision found its initial expression, rather than to the validity of that vision itself, or even to Sun's support of Jini. I will return to Sun's Jini support later. JiniFest provided ample evidence, however, that many developers and the businesses employing them, have already taken the Jini plunge, and are using the technology to solve a diverse array of real-life problems. Here are a couple of examples:

  • While J2EE has traditionally been associated with integrating legacy systems, it is no longer the only Java tool for that task. For instance, LaCrosse must develop a "massively-scalable, self-healing, low-administration reporting system" for an automobile manufacturer. "We need to generate up to one million different reports per day, and distribute them all over the world," he says. "We considered using J2EE, but found it lacking in several areas. First, J2EE is mainly a request/response arrangement. You always need to provide something outside of it for scheduling and monitoring. Second, its huge size and vendor-dependent fail-over and load-balancing schemes are definite drawbacks. Finally, it requires constant administration if your system is growing and changing. In sum, for our application, it was too much cost and work, and in the end, would not have been able to provide the type of reliability we were looking for." Instead, LaCrosse's team chose to build on Jini: they are using a third-party JavaSpaces implementation from GigaSpaces, and Rio, a Jini community project.

  • Oliver Zeng, a senior technical lead with FreddieMac, the US's largest mortgage banker, echoes a similar sentiment: "We use Jini, and especially the JavaSpaces service, in the analysis of our financial models [of more than 10 million portfolio accounts]. These models are very complex, very CPU-intensive and take a long time to run. Our job is to engineer them so that they can run very fast. We used to improve performance by getting increasingly faster boxes, but you soon hit a wall. [With Jini] you can increase performance by adding another machine, without rewriting code. Our models are also very dynamic, and [Jini] makes our system easily adaptable. Jini's protocol independence also allows us to incorporate legacy systems, such as ones based on Corba."
  • Jini's integration ability, due to its communication-protocol independence, plays to the strengths of Valaran, a company building a next-generation environment for managing very complex distributed applications. One of their markets is telecommunications: "The different back-end systems...are truly distributed," says Aleta Ricciardi, the company's co-founder and executive vice president for strategy and innovation "We are dealing with a highly complex, heterogeneous, and nonstatic environment. Jini as an infrastructure for [integrating] these applications was perfect."

To be sure, there are companies that tried Jini, but later abandoned it. One such company is Improv Technologies. They focus on providing XML-based Web services tools and based their early implementation on Jini. But, according to Athomas Goldberg, Improv's cofounder and CTO, Jini lacked the needed security infrastructure their product had to offer. Instead, Improv turned to Jxta, with its ability to bridge network firewalls.

Sun's Jini projects

While JiniFest represented the diverse uses of Jini outside Sun, it also shed some light on Sun's internal support for Jini. Citing the company's internal policy, Hurley declined to discuss the number of employees and the economic extents of Sun's Jini investments. However, he confirmed that the mandate of Sun's Jini team includes evangelizing Jini to other Sun groups. With Sun's goal of increasingly leveraging its existing software technologies, that activity has recently assumed a new level of intensity, according to Hurley.

Already, many internal Sun projects employ Jini. In some cases, the company released the source code for those projects under the SCSL license via the Jini community Website. One such project is Rio. "Rio was part of an effort Sun had with Raytheon, working on a US Navy project," explains Hurley in a phone interview from Sun's Burlington, Mass. campus. "[The Sun team] thought that their work was applicable in a wider context, and wanted to share it with the community. They had a sense that [Rio] could help the wider Jini community build better services."

Sun's Rio team, Hurley adds, enjoys receiving feedback from the Jini community. "I don't believe they have all the source code out there yet [for the community]," he says. "But they received a lot of feedback on the ideas of quality-of-service, service provisioning, and the Lincoln-tunnelling work." (Lincoln tunnelling allows multiple Jini federations to connect over a wide-area network.)

A major auto manufacturer is now benefiting from Rio. "Each Jini service is written as a Jini Service Bean [a Rio feature], or JSB, that is automatically provisioned to one or more Cybernodes by the Rio provisioning monitor," says LaCrosse. "The major benefits of this are twofold. First, some of the Jini housekeeping is handled by the JSB base implementation. Second, no administration is required when new servers are deployed. We simply would need to load the Cybernode software [offered by Rio] and let it go. The Rio provisioner will use the Cybernode to meet the goals specified for the system by launching additional copies of our JSBs there...If any of the machines go out, Rio will redeploy the lost JSB automatically to the other remaining systems."

Jiro offers another instance where Sun took an internal project, released parts—or all—of it to the Jini community under the SCSL license, and received feedback from the community. "Jiro was an effort inside Sun for a couple of years to provide storage-system-management solutions," says Hurley. "Lots of people thought that the ideas that Jiro had offered were applicable to other [systems management] domains as well. Sun decided not to continue the Jiro work separately any more, but since Jiro was built on Jini, and many in the Jini community had looked at Jiro, they contributed the technology...to the Jini community."

Jini might also infuse other Sun internal collaborations. While Hurley and other Sun employees refused to comment in detail, they acknowledge a level of collaboration between Sun's Web services and Jini teams. When pressed about this issue, Hurley noted only that, "Things are happening within Sun's software division. And some of that has to do with aligning Java, Web services, and Jini."

Outside of Sun, Jini has found its way into other large organizations, often through a back door. PsiNaptic was the first to offer a full implementation of the Jini specifications aimed for devices with limited capabilities. That makes their Jini offering attractive to companies developing telematics products—for example, systems inside cars. "IBM made the decision a good 10 years ago," says Arato, "that they were going to supply the automotive industry with advanced technologies. IBM will integrate PsiNaptic's Jini implementation with the WebSphere Micro Environment and WebSphere Studio Device Developer. Jini being added to WebSphere is a way IBM can differentiate their platform."

Java's secret weapon

The notion of combining Jini with Web services' objectives suggests that perhaps Jini is Java's secret weapon. For a secret weapon to be effective, it must address a marketplace need hitherto unrecognized by others and, at the same time, it must be kept, well, secret until the time arrives for its full-scale deployment.

To gauge what unmet market demand Jini might have in mind, consider the following:

Microsoft CEO Steve Ballmer: There are many islands in this world, and that's why this federation concept gets increasingly important. We're betting that...it's not going to be just a world of browsers.

Microsoft Chairman and Chief Software Architect Bill Gates: When we think about knowledge workers, they're not paid simply to click through screens and read what's there; their value added is taking that information and synthesizing it.

Ballmer: We're betting that the whole world does not move to a mainframe model of centralized computing...I'm going to suspect that you still are asking yourselves a few questions. One question might be...what is .Net? Unlike Windows, where you could say it's a product, it sits one place, it's got a nice little box, who's the competition. In some senses it's a very good question. There's no competitor who's announced their .Net. I feel very confident that the XML revolution will happen..."

The excerpt is from a July 2000 presentation on Microsoft's first plans for .Net. It highlights the key motivations, not only behind .Net, but also behind XML-based Web services: in Gates's words, "synthesizing" information from diverse sources and attempting to build a software platform based on the tools used for information sharing, namely, XML.

The first aspect of the Jini vision includes that vision of information sharing. That vision is what Joy referred to during the initial Jini Community Summit when he said, "Web and email are what people care about when they turn the machine on. Many people would prefer a simple machine that is more communications-oriented." In that context, the communications-oriented machine would deliver chunks of data—or mobile data—such as email messages, text, or images used in a Webpage, across the network to satisfy a human user's needs.

XML-based Web services architectures extend that simple notion of mobile data with the capability to perform some processing as data arrive from the network. When encoded in a special format—for instance, in a SOAP (Simple Object Access Protocol) envelope—data aimed for a human user can carry a piece of additional data aimed, not for a human, but for that user's machine, or some other machine en route to the user's machine. That extra data chunk then causes software installed on those machines to execute a set of functions.

That model's key requirement: For that execution to occur, the needed software must be present on every machine where the execution should happen, prior to the arrival of a message triggering the execution. A simple analogy illustrates that requirement: When you double-click on a file icon inside a folder of your computer's user interface, that action causes the operating system to execute the program it has associated with the particular file type. If that program is not installed on your computer, your operating system can't do much with it.

Java's RMI mechanism removes that software requirement: along with the action comes the software that actually performs that action. In other words, with RMI the data plus the codes required to process that data come via the network.

The second aspect of the Jini vision takes advantage of mobile code. Mobile code initiates the changing relationship between parts of a computer, which Waldo alluded to in his talk at the Aspen Jini meeting. For instance, mobile code allows a computer to download parts of its crucial operating code. It also enables a Jini proxy to download its implementation into a client's address space and execute there, without that client requiring prior knowledge of that implementation.

Page 3 of 3

The difference between mobile data and mobile code is easy to illustrate: Suppose I hand you a piece of paper—a document—with a fairly complex quadratic differential equation scribbled on it. In the paradigm of Web browsers and simple email, you would simply display that document without any further processing. In the world of XML-based Web services and SOAP, you would process the document upon receipt, possibly solving the equation. Imagine, however, what happens when you receive such a document but do not know how to solve differential equations. Even if I place a special note on the document asking that you, please, solve the formula before displaying it, you can't do that without knowing how. In the mobile code world, I would not only send you the differential equation, but also the instructions needed to process it. You could load those instructions into your mental "virtual machine" and solve the formula. Thus, although you lack prior capabilities to process a piece of information that came from the network, the network provided you with the solution—the instruction codes—needed for that processing.

Unfortunately, the third, and most powerful, component of the Jini vision lends itself to no easy example from everyday human interaction. Recall Joy's description of Jini as a "BIOS:" He claimed that objects "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 its most basic definition, an object is data plus code. In that sense, a mobile object exploits the best combination of mobile data and mobile code. An example of a simple mobile object is an immutable Java entity bean that arrives via the network and provides accessor methods to obtain its data. However, an object not only represents code and data, but also a computation: the data carried by a mobile object is not only data intended for humans, or data intended for a remote processor, but also data that possibly captures the state of an ongoing computation. For instance, a processor might start to solve your differential equation, then freeze that computation's state, and transport the object to another processor, which would resume the calculations.

Thus, while XML-based Web services allow federating information, and while the current use of Jini goes a long way towards federating computation resources—such as devices, software components, and services, or, as in the case of Rio's Cybernodes, even entire servers—the full potential of the Jini vision goes a step beyond that and allows the federation of computations.

While mobile objects require mobile code, they introduce a higher-level abstraction to network-based resources. Consider the following example: You want to talk to a German client on your mobile phone. Since your German is rusty, you request from a software provider a real-time German translation program. With mobile data, you would probably receive an XML file, containing German word definitions and grammar rules that would plug into your phone's built-in translation software. With mobile code, the class files for the translation software would also download into your phone's JVM via class loaders and initialize there upon arrival.

In the world of mobile objects, a remotely running translation software might decide to dispatch first a small proxy object to your phone. The software would then run at two places: it will do most of its work remotely, while a piece of itself runs inside your phone. Since it would also monitor resources used in that process, at some point, it might decide to switch to a more efficient communication protocol, given available network bandwidth. Or, it might decide to move some objects from the remote host to your phone, resources on the device permitting. Many similar scenarios are possible with mobile objects. The cell phone does not have to care how the translation software works; it only cares about the interfaces the software implements.

Jini paves the way

Many of Sun's competitors develop systems that feature data and code mobility.

XML-based Web services exemplify the former; for mobile code, consider the ability of Microsoft's .Net framework to load DLL (dynamic load library) files dynamically from any network location into the .Net common runtime. However, to my knowledge, no company so far has come forward with a widely available, commercial system that features the mobility of computation, or object mobility. To paraphrase Microsoft's Ballmer, there's no competitor who's announced their Jini.

Jini's real test is how developers apply Jini's mobile object paradigm to their problems. Leveraging that capability might lead to applications that eclipse the flexibility and ease-of-use of much of today's software. The Jini community's progress has already shown developer ingenuity in putting Jini to novel uses. With Jini's increasing popularity, it serves as Java's secret weapon, and will likely pave Java's, and Sun's, way into the future.

Frank Sommers is founder and CEO of Autospaces, a company focused on bringing Jini technology and Web services to the automotive software market. He is also chief editor of the Newsletter of the IEEE Task Force on Cluster Computing.