Rob Gingell (pronounced "jingle") is Sun Microsystems' chief engineer, a position that gives him oversight of all of Sun's developments and directions. Born in the Washington, D.C. area, he pursued his studies at Case Western Reserve University in Cleveland, Ohio, where he worked on projects for the US government's Advanced Research Projects Agency (ARPA), an early sponsor of the Unix operating system and the Internet. Upon graduation, he continued his work at the university for eight more years when, in 1985, Gingell moved to the West Coast to work for Sun on the company's next-generation operating system. In that capacity, he developed a new dynamic linking mechanism and contributed to defining the ELF (executable and linking format) object format, which has since become the standard binary file format on most Unix operating systems, as well as on Linux. Much of that work led to the definition of the Solaris ABI (application binary interface), which guarantees that a binary program runs on different versions of Solaris, as long as that program conforms to the Solaris ABI. (By contrast, an API guarantees a developer's access to a library's function and method definitions, as long as that library conforms to an API.)
As part of that work, Gingell contributed to the development of System V Release 4 (SVR4) Unix, a work performed jointly with AT&T Bell Laboratories. Sun's Solaris Operating Environment is based on SVR4 Unix. In 1994, Gingell became a Sun fellow, joining the ranks of Sun notables like James Gosling; by then, he was overseeing Sun's diverse software projects. He also served as Sun's representative to computing standards organizations, including X/Open and OSF (now The Open Group). Recently, Gingell has served as chair of the Java Community Process (JCP), which governs the evolution of Java and the JDK.
Jini community members know Gingell as a 2001 JiniJam participant, and, in his own words, as a Jini fan. I interviewed Gingell via email in June to discuss Jini's role in Sun's new software organization.
Read Gingell's complete interview in "Jini's Relevance Emerges:"
- Part 1: Sun's Rob Gingell discusses Jini's role in the future of enterprise computing
- Part 2: Gingell compares Jini's approach to enterprise computing with Web services
Jini's future at Sun
Frank Sommers: Sun recently announced an ambitious restructuring of its software organization, bringing its software offerings under one umbrella. What role will Jini play in that new organization?
Rob Gingell: Like other living, dynamic organizations, Sun periodically reorganizes itself. These organization structures often have shorter lifetimes than the products and technologies the company produces. In that respect, the new organizational structure doesn't directly impact Jini, Java, or Solaris.
On the other hand, the shift reflects Sun's evolution from a company that delivers value out of VLSI [very large scale integration] and operating system platform integration to one that builds systems out of the network, based on components that tend to carry IP addresses. That new focus is based on what we, and the industry in general, have accomplished over the last couple of decades and asks the question: If the network is, indeed, the computer, then what computer should we make out of the network?
The artifacts that make up the network components today are realized extensively in software technologies. Sun's recent organizational shifts result from the need to mine our existing software assets to provide the next wave of systems technologies. This shift has happened before at Sun: the original software group was named the "systems group" for a similar reason.
Some of Sun's internal projects in the construction of our next-generation systems have already started to employ Jini. That usage is independent of the organizational changes per se, but not of the general flow that has us forming next-generation system components out of our software assets.
I previously called Jini one of the first mammals in networking evolution. True network-based systems must be constructed differently from their predecessors or from systems that are merely network-attached. Sun launched Jini to explore the possibility of true network-based systems. That we are starting to employ Jini internally reflects part of what we learned from that exploration, and that the company is moving toward a new generation of thinking about the products it builds.
Sommers: What are some of Sun's Jini-based projects?
Gingell: A key aspect of Sun's internal use of Jini is in managing system resources, including networks of software and hardware components. Jini will likely provide the backbone of the administrative environments we supply in the future. Thus, Jini will play a big role in the systems that Sun builds. You will see that use in our products in probably two years, perhaps sooner.
A premise of these systems is that they must deal with the world as it exists—the Internet will never reboot and neither will the portion of the Internet that lives within a customer's environment; at least we can't assume it will reboot. These systems will be heterogeneous in ways not currently visible in our products or support offerings, or those of our competitors.
Sommers: Is Sun's use of Jini initiated by high-level management or from the grass roots?
Gingell: In this particular case, I'm the project's creator and the one insisting that we use Jini in it. I think of this project as a more bottom-up case—though, in some contexts, people regard me as high-level; a few errant souls even think I might be management. Most, but not all, Sun projects tend to get driven bottom-up. In this case, it's a bottom-up project driven by a high-level person. Nevertheless, Jini is being pushed because it's the best technology for the project.
Sommers: A recent New York Times article, published on May 3, 2002, ("Unfazed by Defectors, Sun's Chief Charts Next Era," John Markoff) quoted Sun Chairman and CEO Scott McNealy as saying that Sun intends to reverse the software-to-hardware ratio in its product offerings. According to the article, that ratio currently stands at about 30 percent software to 70 percent hardware. The same article also quotes McNealy as stating that Sun aims to sell "metal-wrapped or plastic-wrapped software." By contrast, Microsoft, often portrayed as a Sun competitor, seems to stake its future revenue growth on selling software as services. What part of Sun's expanding software revenue will come from selling software as services? Will some of those services be Jini-based?
Gingell: Your question relates to two distinct things: how a company obtains revenue for its products—one-time sale versus a leasing-, annuity-, or usage-based pricing—and, second, what kind of company you are. As to the latter, Sun is, and has always been, a systems company. Analysts and the press know how to look at hardware or software companies, but don't really seem to understand systems companies. That's understandable because, aside from Sun and on alternate days IBM, there aren't many of us to form a basis for comparison.
Hardware companies tend to follow their initiating technologies into commoditization, becoming service companies or commodity suppliers, or both, in the end. Software companies tend to return large gross margins on high-valued products. A systems company tends to make products that are integrations at some level. Successful systems companies jump up levels as a given level commoditizes. A systems company can translate a realization of computation between hardware and software, and create a packaged integration that offers superior value to, say, a collection of boxes that need a bunch of service products to integrate.
At Sun, we build computing systems. We may use ASICs [application-specific integrated circuits], processors, programs, data, or other content in the realization of those systems, and any given component might be realized differently at different points in time. As a systems company, we can use our expertise in building chips, operating systems, and programming platforms in achieving a solution where others might be able to operate in only one domain. I've mostly been involved in software in my career, but I don't think of myself as a programmer—I think of myself as an engineer who can use programming to affect a solution. It might be true that if you inspect the status of software-to-hardware, it will tend towards the software ratio. Even our microprocessor designers are more programmers than anything else.
As for how a company obtains its revenue, customers want to price computing assets—whether in software or hardware—flexibly. Service-based pricing tends to offer that flexibility and thus pervades the industry. I'm expecting that some of what we build will be built out of Jini. Whether that Jini-ness will be externally visible is still an open question. I want to build a few projects partly to see what makes best sense.
Sommers: When Jini debuted in 1999, its initial message was the benefit of interoperating devices. Do any of Sun's current hardware offerings come Jini-enabled? Will Sun bundle Jini with Solaris?
Gingell: No product you buy today comes Jini-enabled. This will change over the next couple of years, such that we'll be selling parts that can participate in a djinn [a Jini federation]. Some of those parts, as I mentioned, will constitute a distributed system's management layer.
At that time, we will deliver Jini through the Solaris channel. But Solaris, as a system that operates computer boxes versus a network, will be more a carrier than an embedded usage of Jini, at least with respect to the management djinn. Other djinns, however, might constitute such embedded Jini usages. For instance, the printing infrastructure persistently nibbles at Jini.
Note that the way I've described this usage differs from how we first introduced Jini. By design, Jini directly confronts many networking fallacies. One such fallacy is that a network has one administrator. That statement is fallacious in two ways: first, that there is an administrator at all and, second, that if there is an administrator, there is only one.
The marketing messages and initial push appealed to the no-administrator idea. That has not really played out: Jini has not become the exo-skeleton of a system, defining the means by which previously unrelated things find each other. It has instead found more quiet usage as the "endo-skeleton" of an application: Internal to that application is a Jini environment, and the application exhibits interesting properties in deployment because of Jini's presence. But that application's Jini-ness isn't visible to those outside the djinn who perceive it as something else—as a Web service perhaps.
One of our struggles with Jini's perception resulted from our initial push, which was a well-executed pitch and a message with great appeal. It caused everyone to look towards the western horizon, expecting, at any moment, a horde of devices to rush over the hill, all Jini-enabled. Those devices haven't arrived. Because we stared in that direction, we did not pay attention to the eastern horizon, where many of these embedded Jini usages have come into play, where people are executing commercial licenses and making products with Jini.
Someday, given a sufficient population of such embedded usages, their Jini-ness could start to reveal itself to the outside, and our original emphasis will be realized. If you're an optimist, instead of saying our original vision for Jini hasn't happened, you say that vision hasn't happened yet. That's not a foolish optimism: some in the industry viewed the initial deployment of Java to desktop computers and some of the fragmentation that occurred as meaning that "client Java failed." But client Java wasn't, and isn't, about just desktop computers; it's about the space of IP-addressable access points in which desktop computers will shortly be an important minority. Client Java is only now really happening.
Technologies in general, and software systems specifically, are living things that, when launched, embark on a journey. They interact with their environments and evolve. A novel technology's success often occurs differently from what might have at first been desired, expected, or advertised. While we must be consistent with the purpose for which we planned, we also need to learn and adapt to life as we find it, not just as we declared it.
Jini, Web services, and Sun ONE
Sommers: Sun is currently devoting significant resources to the development and promotion of XML-based Web services technologies. However, many in the Java community view Web services as a setback: sending XML documents across the network amounts to transmitting chunks of data, whereas network-mobile Java byte code allows one to send not only data, but full objects down the wire. Many developers that have tried Jini believe it is the ultimate Web services technology, as it takes full advantage of Java's object mobility capability. How do you view Jini's relationship to Web services?
Gingell: Web services is an often muddied term. I'm going to use your question's definition: Web services are an arrangement of network protocols in which HTTP provides a transport layer, and XML-defined protocols provide the session and presentation layers, along with a set of expected support services.