Jini's relevance emerges, Part 2

Sun's Rob Gingell compares Jini's approach to enterprise computing with Web services

In Part 1 of this interview, Sun Microsystems Fellow and Chief Engineer Rob Gingell discussed the role of Jini in Sun's new software organization, the relationship between Jini, Web services, and the Sun ONE (Open Network Environment) initiative, and the rationale for document-centered Web services versus mobile object systems. He concludes his discussion by comparing Jini with Web services, questioning Jini's role in the JDK, and sharing his summer vacation plans.

Read Gingell's complete interview in "Jini's Relevance Emerges:"

Frank Sommers: A key Jini feature is its ability to handle partial failure in a distributed system. At their current specification level, Web services technologies seem to ignore the question of failure handling at the application or session layers, and instead suggest that the network-transport layer handle failure resilience. If someone pulls a network cable from a server, network transport software cannot help that situation, and that failure will affect the application. In that same situation, a Jini system would raise a remote exception, an object that allows a Java program to intelligently respond to that failure. Why do you think Web services technologies paper over the question of partial network failure?

Rob Gingell:
For most of the last 30 years, the industry has been trying to render the network transparent to applications. An RPC [remote procedure call] makes a remote call appear just like a local procedure call. Distributed resources pretend to resemble local resources—remote files, just like local ones. The Web services environments, CORBA, client/server computing, and even J2EE [Java 2 Platform, Enterprise Edition] continue this practice, insulating the programmer from the bad old network.

So far, we've gotten away with that because the systems we have built are relatively small. As the parts count increases, and as we expose our systems to increasingly raw and unpredictable environments, the likelihood that something won't work will also increase. As that occurs, all the transparency mechanisms we placed our confidence in just get in the way: obscuring the failures makes it difficult, and even impossible, to know what's going on in the system. We will soon come to think of this practice as the computer industry's version of bleeding the sick with leeches: it seemed like a good idea until we learned better.

Computer scientist Peter Deutsch, who worked for Sun in the early 1990s, coined a set of distributed computing fallacies, listing all the kinds of leeches we use: distributed systems' old assumptions, which, in general, are completely false:

  • The network is reliable
  • Latency is zero
  • Bandwidth is infinite
  • The network is secure
  • Topology doesn't change
  • There is one administrator
  • Transport cost is zero
  • The network is homogeneous

Web services continue this tradition similarly to how many of us have perpetrated those fallacies for the last several decades. However, some people and problem domains have already experienced the fallacies' effects, an experience that seems a shared characteristic of the folks I meet in the Jini community. Through their experiences, Jini community members see that they must approach the network differently.

Sommers: What will happen when millions of Web services interact in sophisticated ways and some start to experience partial failures?

Gingell: With respect to millions of Web services interacting, I don't think that's ever going to happen. I realize, though, that the notion is a popular part of the Web services hyperbole. Millions of Web services will never interact with each other because the application domain doesn't need such functionality. Most business networks—the transaction chain a business completes—are relatively simple. They don't go more than a couple of layers deep. Also, the social, legal, and sometimes regulatory environments in which these networks exist limit their complexity. Business networks are also relatively static. I imagine, for instance, that Ford would be annoyed to discover that its computers were negotiating with Firestone's computers just because it became technically feasible for them to do so. Millions of transactions will occur, certainly, because automating the repetitious is an obvious task for computing systems. But the chain of systems being automated will remain relatively simple.

Should distributed systems become more complex, then the networking fallacies' liabilities will start affecting them, revealing those systems' shortcomings. That isn't a limitation of Web services alone. Again, it's a consequence of years of industrial habit. But this gets back to why we do Jini: to show us how we should be doing things differently as the problems and their scale evolve.

However, we're not inevitably headed for a "Wile E. Coyote" future—where we run off a cliff, and gravity avoids us until we finally look down. The situation is more like Newton versus relativistic physics. Einstein showed that Newton was only approximately correct. But that approximation works pretty well for most of us most of the time; GPS [global positioning system] is probably the only system we somewhat routinely interact with that must compensate for relativistic effects.

Change on the network

Sommers: In a distributed system, such as Web services, change appears constant: a business can add, change, or remove any Web service without consulting others using that service. XML-based Web services seem lacking in their ability to handle such changes. For instance, UDDI [Universal, Description, Discovery, and Integration] service registrations are not bound by time: stale service registrations remain in UDDI registries until someone explicitly removes them. Jini solves that problem by restricting access to network resources with time-based leases. Wouldn't a non-Jini Web service approach hit a wall when the number of Web services reaches critical mass? What is your opinion? Should a Jini-like mechanism, such as a lease, be proposed for XML Web services?

Gingell: There is a threshold where a given system reaches a chaotic, and even fractal, behavior with respect to the status of its resources and the sort of background "hum" of constant churn or revision. The network's eighth fallacy, that it is homogeneous, means much more than simply differing operating systems, processors, or languages.

Those with experience only with single computers or small numbers of systems often engineer these systems such that they need periodic, gross synchronization. Historically we solved that requirement by rebooting our systems. If we had a set of them, we shut down and updated them. If we were lucky, we could make a rolling change during a small time window. We sometimes referred to those reboots as flag-day events.

The Internet will never reboot. There will never be a flag-day event on a large scale, because one cannot exist. We must engineer Internet-native systems to accommodate constant change. The system's scale—the number of components that compose it—determines the degree of constant change.

As I mentioned earlier, I think Web services' scale in the near future will prove modest. Until we solve the issues of cross-environment identity, most deployments will occur within the scope of a given enterprise, expanding, with time, to supply chains and then to customers. Even at those scales, the complexity may not be much higher than that of current systems. For instance, registries with stale entries may be ignored, and that may mean the only generally useful registries will be maintained by large, well-known industry associations or trusted brokers. Such centralization itself would seem to ensure a modest scale.

Over time, the ideas that originated with Jini may reflect in other systems' designs. Some people have already begun thinking about exporting Jini's ideas into these other worlds, which would prove reasonable when those worlds reach a large scale. We don't know whether such ideas can realistically be added and to what degree to Web service architectures. Leasing registry entities is probably doable. Pervasively introducing the idea that you never really own a network resource probably won't be so easy to retrofit for Web services.

Network polyarchy and intellectual property

Sommers: In 1971, political scientist Robert Dahl published Polyarchy: Participation and Opposition in which he addressed the question of how a political system lacking explicit freedoms can transform into a more democratic system. The process implies that many power centers spring up and collectively assume the power of the state, as opposed to having just a few all-powerful centralized entities. His discussion seems relevant to the software landscape today, where currently a few large companies determine technological directions, even if those directions are not always based on the most accurate ideas. An original Jini vision was that Jini might bring a polyarchic organization to the software world: Jini allows software to be composed out of other Jini services, permitting anyone with a network connection to build and contribute pieces of a larger system. Dahl was among the speakers at the first Jini community meeting in Aspen [Colorado] in 1999. Do you believe that his vision remains valid?

Gingell: I do hope that your description of Dahl's vision remains valid. As we begin to think of systems consisting of many components, fractal behavior at the edge will give rise to polyarchic notions. Those notions resemble how combinatorics cause scaling to race beyond the limits of restraining forces, such as industry politics.

But there is also a reason for today's picture. The intense expense of creating and deploying technologies and networks motivates organizations to try to minimize risk. That is partly why you see large players using standards as a proxy for the marketplace: "Even if this is wrong, we're all wrong together." Lowering the risk by reducing a project's size requires smaller entities to "conspire" at the network's edges, defining new resources and systems. We've seen a bit of that with technologies like Napster. Such processes will inevitably continue.

But a change in attitude towards intellectual property protection will enable the real revolution. Much of the industry, Sun included sometimes, thinks of their IP assets as real estate—once sold, forever gone. Yet, that behavior is typical of an entity scared that it has generated its last idea and better hold on to the ones it has for as long as possible. A different view—one more often practiced by Sun—is that ideas resemble renewable minerals: mine them, move them, mine some more. This view is partly why Sun has often made available technologies that others would have naturally retained as a competitive advantage. While we've experimented with different ways of manifesting this view over the years, I cannot think of a case where we've kept something just locked up and secret.

Sommers: Since Jini's introduction, we have not seen increased democratization of the software industry: members of Web service technical committees seem to come from the same large companies, advancing the agenda that best suits their employers' business interests. That situation has proved frustrating to startups focusing exclusively on Jini. For instance, many of their prospective customers at large corporations object to Jini's use, saying that no major corporation stands firmly behind the technology, and that even Sun is ambiguous about Jini, as it offers both J2EE and XML-based Web services to solve enterprise problems. What strategy would you suggest to Jini developers when they approach prospective customers?

Gingell: When I talk with customers about their problems, I try to understand what systems they have in hand, what they're trying to do, what their experiences and goals are. For customers with an existing IT investment that they're not contemplating re-engineering, I suggest they head for the J2EE environment. I tend to point Jini towards those who lack that constraint and, more important, already show an understanding of the network's fallacies. In my experience, most people fall in the former class—but not all people. I'm seeing an increasing number of the latter class, particularly in areas other than transactional or enterprise computing. Distributed command and control, the rise of sensor networks, media computing, and dynamic evolution of any system all promote discussion of the Jini concepts.

Looking at customers in that manner isn't difficult. Indeed, just about any car salesman does it. When you walk into a major automobile manufacturer's dealership, a salesperson can sell you vans, minivans, light trucks, sedans, station wagons, and even sometimes an approximation to a sports car. Still, I appreciate that though the sell isn't hard, it could be easier. This is partly why we've spent some energy thinking about internal Jini applications and are now starting to proceed in earnest. As we get closer to the problem of general networks, the issues that Jini addresses become more apparent. As we get closer to making computers out of the Internet, we'll need systems with the properties Jini provides. Once Sun rolls out one of these projects, we'll still have J2EE, Web services, and the like, but showing that we not only make Jini, but also use it will at least give people a Sun-based reference point.

Sommers: The JDK has grown with each release. The current standard release includes database connectivity, XML-processing, regular expressions, multimedia, and many other capabilities. Will Jini one day become a part of the JDK to offer Java a distributed computing capability? How would you advise the Jini community to propose Jini's inclusion in the JDK?

Gingell: One of my jobs is to chair the Java Community Process [JCP], which is how the Java specifications evolve. Keeping that process a useful, vital way for the industry to move forward specifications in the java.* and javax.* namespaces proves important.

But the JDK is not a system, nor does the JCP describe all uses of Java or all the systems that could be composed from Java. Even J2EE is not really a system in the general sense of the word. Indeed, no one has yet built a useful networking system that meets a key system characteristic of being self-supporting. I would be loathe to put a single system personality into Java as the system for Java—that would be antithetical to the other concerns you expressed earlier about Web services as well. Java is a platform in the sense that it defines a binary execution environment, but it is less than a system because that environment admits to a variety of network organizations. That seems a valuable thing we ought to maintain.

Some tasks that originate from the Jini group have usages more general than Jini, RMI being the original example. Having those tasks and adding others like them over time would offer a useful outcome. Otherwise, I like having the Jini community consume the Java community's work.

Public Jini service registries?

Sommers: In an interview at the 2002 JavaOne Conference, you remarked that for Web services to take off, a certain critical mass of seed services, such as Web service registries, must exist first. Is Sun planning to offer some of those seed services? If so, will some be Jini-based?

Gingell: In that remark I was thinking of having enough public UDDI registries and sufficient identity resources available. We might be an operator of such a registry at some point, though generally, Sun does not operate or provide public network services. Instead, we provide the equipment and resources by which our customers operate those services. In that respect, we differ from a company like Microsoft, which, in addition to being a product supplier, is also a service operator and a content provider. Our customers are service operators and content providers, so they would naturally be the ones creating such services. We help them by providing products that embed templates of common services—perhaps very complete templates.

Sommers: With Sun being a founding member of Liberty Alliance, will the company offer a Web-based identity service similar to Microsoft's Passport? Given that such a service must operate on a large-scale network, if Sun offers it, would it be based on Jini?

Gingell: Liberty Alliance is mostly populated, not by equipment or product suppliers, but by the customers of the information technology industry. These are the companies who, outside the Internet context, already own or operate identity resources in one form or another. Liberty Alliance is about enabling those customers to employ their identity assets in an infrastructure they have already built and that works on the Internet, especially in the Web services context. We're involved in helping them achieve those assets on the Net. We might supply some of them with products that do that work for them, but they'll operate the services and hold the identity assets, just as they do today.

Sommers: To conclude the interview, I'd like ask you about something quite different. I read that you are an avid pilot and that you typically take a cross-country trip every year. Are you planning such a trip this year? If so, what will be your flight route, and how many days will it take to cross the country?

Gingell: In recent years, I've made many such trips, somewhere between three and five. This year, I plan to head from the [San Francisco] Bay Area first to Oshkosh, Wisconsin for an annual flying convention. That trip usually takes two days, spending the first day arriving in the vicinity of Oshkosh and then taking a short hop to the city so I arrive with mostly full fuel to loiter for a while, in case the arrival to the convention gets too exciting. After that, I'll head to the Maryland/Washington, D.C. area, and parts of the East Coast.

Currently, I fly a twin-engine Cessna 310. I usually fly about 210-220 MPH through the air. If I didn't need to stop for fuel and other needs, that speed would fly me coast to coast easily in about 11.5 hours. With stops, it accumulates to about 14 hours. While people do take long road trips these days, generally, flying is much easier than driving: cars don't have autopilots, and when you fly, you're usually miles away from any other airplane and don't have to worry about what the airplane in the next lane might do. Also, there are no traffic jams and such. Nonetheless, I don't usually cross the country in one day. It's a hard trip; and part of the fun is stopping off, seeing someplace new, relaxing, just being out and about.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies