Jini's relevance emerges, Part
2
Tutorial Details:
Jini's relevance emerges, Part 2
Jini's relevance emerges, Part 2
By: By Frank Sommers
Sun's Rob Gingell compares Jini's approach to enterprise computing with Web services
n 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:"
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
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 polit
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Jini's relevance emerges, Part
2
View Tutorial: Jini's relevance emerges, Part
2
Related
Tutorials:
 Jini: New
technology for a networked world - JavaWorld June
1999
Jini: New
technology for a networked world - JavaWorld June
1999
|
The state of Jini technology - JavaWorld
The state of Jini technology - JavaWorld
|
How to attach a user interface to
a Jini service - JavaWorld October
1999
How to attach a user interface to
a Jini service - JavaWorld October
1999
|
Make room for JavaSpaces, Part 2 - JavaWorld January 2000
Make room for JavaSpaces, Part 2 - JavaWorld January 2000
|
Create automated and distributed
management applications with Jiro
technology, Part 1 - JavaWorld February
Create automated and distributed
management applications with Jiro
technology, Part 1 - JavaWorld February 2000
|
Make room for JavaSpaces, Part 3 - JavaWorld March
2000
Make room for JavaSpaces, Part 3 - JavaWorld March
2000
|
Make room for JavaSpaces, Part 4 - JavaWorld April
2000
Make room for JavaSpaces, Part 4 - JavaWorld April
2000
|
Activatable Jini services, Part 1: Implement RMI activation - JavaWorld September
2000
Activatable Jini services, Part 1: Implement RMI activation - JavaWorld September
2000
|
Activatable Jini services, Part 2: Patterns of use
- JavaWorld
October 2000
Activatable Jini services, Part 2: Patterns of use
- JavaWorld
October 2000
|
Sun lets Jini
Starter Kit 1.1 out of the bottle - JavaWorld December
2000
Sun lets Jini
Starter Kit 1.1 out of the bottle - JavaWorld December
2000
|
Object mobility
in the Jini environment - JavaWorld January 2001
Object mobility
in the Jini environment - JavaWorld January 2001
|
Survival of the fittest Jini services, Part 2 - JavaWorld July 2001
Survival of the fittest Jini services, Part 2 - JavaWorld July 2001
|
Jini-like
discovery for RMI
Jini-like
discovery for RMI
|
Jtrix: Web
services beyond SOAP
Jtrix: Web
services beyond SOAP
|
Unleash mobile agents
using Jini
Unleash mobile agents
using Jini
|
Jini's relevance emerges, Part
1
Jini's relevance emerges, Part
1
|
Java's secret weapon
Java's secret weapon
|
Jini's relevance emerges, Part
2
Jini's relevance emerges, Part
2
|
Jini Starter Kit 2.0 tightens Jini's security framework
Jini Starter Kit 2.0 tightens Jini's security framework
|
Call on extensible RMI
Call on extensible RMI
|
|
|
|
