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.

1 2 Page 1
Page 1 of 2