Jini’s relevance emerges, Part 1
Sun’s Rob Gingell discusses Jini’s role in the future of enterprise computing
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.)
Rob Gingell
 |
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.
Jini’s relationship to such a network is that it is a technology for constructing a system that can offer its functionality as Web services or can consume Web services offered by others. The Web services network architecture doesn’t say much about the black boxes that the architecture connects together; those black boxes might represent other networks, for instance.
A Jini system, a djinn, is also an arrangement of protocols and related services. As you noted in your question, one of its distinguishing features is the Java object model embedded in that arrangement’s session and presentation layers. The Jini architecture does not presume the Web and its protocols. Instead, it primarily assumes the same basic Internet environment the Web itself requires. The Web and Jini represent parallel, but distinct, network protocol architectures.
That leads us to a source of confusion that confronts many and includes the notion that Jini is the ultimate Web services technology. The confusion has its root in the conflicts between OS platforms over the last couple of decades. Traditionally, the choice of an OS represented taking a fork in the road: choosing X precludes choosing not-X, which is similar to what logicians call the principle of the excluded middle in contemplating a system’s structure. Applied to networks, the principle asserts that if I use the Web services architecture, I’m precluded from using the Jini architecture (or others), and vice versa. Yet, if that were true, my remark about using Jini to construct a Web service would be nonsensical.
As a virtualized machine uses recursive layering to permit multiple operating systems to coexist where normally they would preclude each other, the layered network model permits the coexistence of otherwise distinct architectures. And the common layers permit those architectures to intersect and inter-relate. That helps Jini act as a system implementation tool, and the resulting djinn to participate in many networks, not just Jini-architected ones. Given that Jini is more abstract than the Web, it is the ultimate services technology, since the Web more or less assumes you’re living on the Web’s protocols, not directly on the Internet’s protocols.
Distinct but intersecting planes of commonality is an important notion in networking: It enables VPNs [virtual private networks] to exist and permits the decomposition of protocol handling into firewalls and layer-dependent content switchers. The notion’s most important value to people investing in computer architectures is that, unlike the traditional issue of OS choice, the network architecture choice for a given application doesn’t preclude interaction with environments where different choices were already made.
Sommers: Sun is currently rebranding most of its software offerings under the Sun ONE [Open Network Environment] umbrella. Yet, the Sun ONE overview diagram and associated descriptions omit Jini. Why is Jini not part of Sun ONE?
Gingell: Your choice of the verb omit—as opposed to exclude—is a good way of expressing the situation. True, the Sun ONE literature doesn’t show how to use Jini in the manner I’ve described. But Sun didn’t publish any literature showing how to use Jini to build a Web-based environment as opposed to using a J2EE [Java 2 Platform, Enterprise Edition]-based application server either, yet such usages of Jini exist. Such descriptions could be written. We haven’t written them yet due to time and resource constraints, though you may see them in the future.
What has been written to describe Sun ONE reflects market reality: most of our customers do their commercial computing using a J2EE-based application server of some form. J2EE’s success is due to many reasons. Chief among them is that, to many customers, J2EE represents a path of least resistance in bringing their already extant IT environments to the network, especially to the Web. That will probably be true for Web services deployments as well. Most organizations have various IT assets of differing technologies and vintages, and J2EE’s facilities for integrating them have proved attractive to those who want to take an incremental path to the network.
J2EE and Jini are both Java-based environments, yet J2EE has historically focused on integrating heterogeneous resources—a practical CORBA, if you will,—whereas Jini has explored the construction of network-native systems. For the latter, Jini took explicit steps to depart from the status quo.
That may beg the question, “If J2EE is so popular, why bother with Jini?” Nope, there’s that principle of excluded middle again. J2EE is important and popular, but it is not, and cannot be, universal.
The language-independence myth
Sommers: XML represents data in language-independent ways. Since other programming languages can also program Web services, could the proliferation of XML-based Web services ultimately hurt Java’s prominence in the software development process?
Gingell: We respond to both market interest and the competitive environment. Given that developers want to work in a Web services structure, we believe that Java, particularly via the J2EE-based path, will be the most effective way for them to do that. Many developers have told us they want to use Java to build Web services. Enabling J2EE and the products derived from it to support that architecture serves that interest. Developers already use J2EE to integrate programs written in other languages into the Web services environment, which doesn’t weaken Java’s popularity as a programming environment. J2EE’s integration capability actually strengthens Java.
Although Sun played a part in the creation of XML, its application in the definition of a document-based Web services architecture originated elsewhere in the industry. Some pundits—and the paranoid—assert that the reason for that architecture is just what you suggest: to hurt Java’s prominence by inserting a spoiler into the network that prevents the Java object model from assuming a universal status like the IP protocol layer has.
Constructing services from Web resources as the logical “next thing” is a reasonable extrapolation from history: functions are composed into building blocks, programs into libraries, network applications into services. That we see this next thing now, while many organizations are still finding their way to the network, is perhaps a function of some trying to keep the industry in a game in which many others have thus far not been playing at the level they would like. That it arrives with a disjoint technology base further fuels the conspiracy theorists and others who see a different possible evolution. Of course, it’s useful to remember that the other camp has its own set of conspiracy theorists who see black helicopters and attempts at world domination in Java and Sun’s actions.
Sommers: A key Microsoft .Net sales pitch says that it is “programming language independent,” whereas everything with Java is, well, Java-specific. Jini makes language dependence explicit by utilizing the Java programming language type system in service identification. Building large-scale distributed systems independent of a specific programming language proved an elusive goal thus far: XDR [external data representation] or IDL [interface definition language], for instance, focused on the exchange of data or the definition of interfaces, but not on defining the behavior of a single program that extends across the network. Do you believe that language independence is a realistic goal in distributed systems design? Or will it turn out to be a myth?
Gingell: The marketing surrounding programming language independence in .Net is a cruel hoax. It appears to suggest that programs just get promoted into the network or, more important, that promoting programs designed with our old paradigms to the network is useful. It attempts to create a false differentiation between .Net and the Java, especially J2EE, environments, which is needed because .Net is otherwise just so much the same, only different.
Programs predating the network will not likely work as-is when they encounter the network. Single-system or single-machine concepts do not always translate well to a networked environment. .Net features the notion of managed code. Your legacy code or application can’t really take advantage of the .Net environment unless it follows the conventions of managed code. Thus, you have to reconstruct the application, unless it was conceptually, not merely linguistically, matched with the network. Unfortunately, no existing program is managed-code-compatible, except by the wildest stroke of luck. You must do at least some re-engineering.
Suppose you rewrite your favorite program, written in FORTRAN, to be managed-code-compatible. Essentially, you are trying to interact with a document-structured network architecture using a programming language that doesn’t comprehend compound documents. Are you going to wander through all the angle brackets of an XML document from your FORTRAN code? Or perhaps the subelements of the compound directly? Really?
A Java environment already lets you incorporate code written in other languages. Look at most J2EE-based systems. Do you know what the bulk of the code is written in? I don’t. What I do know is that it’s not written in Java. J2EE integrates heterogeneous resources; it’s a multilingual environment. J2EE accomplishes impedance matching with the network through wrapping of the environment. Many find that approach attractive because it matches well with how they acquire and maintain internal skills.
Finally, it’s worth observing that other languages have targeted the JVM; for instance, FORTRAN or Ada, to name a couple. But we don’t yammer about how that makes Java multilingual or solves the network integration problem, because it’s simply wrong to suggest that targeting a common instruction set accomplishes the conceptual match-up required for network-centric computing. To create that expectation is deceptive. The real problem with multilingual notions is not that multilingual programs can’t exist, but that their value is misrepresented.
Power tools for orangutans
Sommers: By promoting XML-based Web services, isn’t Sun missing out on Java’s core benefits that set it apart from other programming environments for distributed systems development, such as object mobility, built-in security, or type safety? While Java has had these features from day one, XML-based Web services offer nothing comparable. Instead of objects (data as well as behavior), Web services center around the mobility of documents (data only); even with XML Schemas, Web services offer no type safety comparable to Java’s; plus, security remains only an afterthought in most Web services architectures. Isn’t Sun trying to water down those Java concepts to suit the XML/Web services world?
Gingell: First, if you value those things, don’t use network architectures that lack them. Second, the existence of the XML-based Web services architecture doesn’t inherently water down Java’s capabilities outside that architecture, though it does affect how, or whether, those properties can be expressed in the Web services architecture.
I agree that a network structure based on document-centric protocols is limiting: definitely limiting when thinking of the Internet as a whole; somewhat so with respect to the Internet subset that is the Web; but perhaps not at all with respect to the problem domain of the basic commerce tied most to the current Web services discussions. You can see this proof point in history: were it true that document exchange was the Internet’s sole use, then the only protocol we would ever need was FTP or, at best, NFS [Network File System]. On the other hand, FTP, NFS, and now HTTP are incredibly important—just not exclusive.
The existence of multiple network models on the Internet is generally a feature, not a bug. While I’d be concerned were it true that Web services were purported to be the Internet, I don’t think that’s a rational or defensible position. On the other hand, basic commerce needs will drive much Internet activity, and satisfying those needs means accommodating many concerns and conditions, and history.
It’s probably worth taking a deep dive into understanding why customers find at least the notion of Web services interesting: It’s the idea that previous unrelated information assets could combine to create a new asset. And the idea becomes especially interesting when the unrelated assets are really unrelated, such as when they belong to completely different entities.
That’s analogous to the idea of two previously unrelated societies meeting each other and how they begin to interact and intermingle, and sometimes even conflict. Societies often start breaking through walls via commercial exchange. For instance, the world reduced Cold War tensions by opening trade. Commercial exchange is a nearly universal phenomenon, relatively simple to understand, and one in which the necessary understanding is quickly reached.
Not surprisingly, as our alienated information systems begin to interact with each other, trade emerges as a significant domain of interest. Trade often manifests as an exchange of documents, synchronous or asynchronous, with relatively simple and pre-arranged understandings about their interpretations expressed in contracts, sales agreements, and the like. That partly explains why the forums interested in Web services have so many business-document underpinnings in their heritage—documents are the lifeblood of business operations; the popular stereotypes about offices’ paper-pushing and red-tape don’t flourish without reason.
There is a certain logic, then, in considering as technologies for this domain a transport based on document exchange (HTTP), especially one that already crosses many organizational boundaries through firewalls permissive on port 80. It also follows that with such a transport, session and presentation layers would also be expressed in document terms, hence an XML-based RPC [remote procedure call] mechanism (SOAP [Simple Object Access Protocol]), and XML-derived presentation descriptions. In the presentation descriptions, the externalized specifications define constraints often arrived at either as a result of standardized practices or after hours of negotiations between enterprises.
Could a more general system be dumbed-down to meet that need? Sure. But I’m reminded of a scene in Butch Cassidy and the Sundance Kid: After a relatively spectacular overachievement in opening a locked safe, Sundance remarks “Think ya used enough dynamite there, Butch?” The same can be said for semantic and code exchange. Powerful to be sure, but those who wield it must be ready for it, not just technologically but in other respects as well. Otherwise it’s like giving power tools to orangutans—always spectacular in its outcome, just not always constructive.
That speaks to where Jini needs to grow and develop. I’m a strong fan of what Jini portends for how we can build network systems. I’m intrigued by its challenge to many of our assumptions about how to build systems because I think many of those assumptions will prove unfounded. But we’re still in the early stages of Jini’s development. Jini’s design intuitions that replace old assumptions have not matured or become habit. The tools to develop, inspect, and manage fully distributed systems are at the stone-knives and bearskins level. Among the many reasons we at Sun do Jini is to promote progress in these areas. That progress is coming, but still more progress is needed.
