Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Jini's relevance emerges, Part 2

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

By Frank Sommers, JavaWorld.com, 08/23/02

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:"

• 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.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.