Level: Introductory Daniel Steinberg (DSteinberg@core.com), Director of Java Offerings, Dim Sum Thinking, Inc.
01 Mar 2001 Jim Waldo spent a day in New York City talking about Jini networking technology and the next generation of distributed problems. He gave a keynote at the International Conference for Java Development and an evening address to the New York Java SIG. This article is a summary of his presentations, including remarks he made in an interview with developerWorks.
What happens when there are many more computers than people, and we don't have
the time to be involved in communications between machines? That was the question posed by Sun Distinguished Engineer Jim Waldo as he talked about how computing and communication must change to provide us with more services without the need for more human interaction. Once pervasive computing is a reality, it won't be possible or desirable for humans to
be involved when computers and networks communicate. Jim Waldo looked at the current state
of distributed computing and shared his guesses about the future. Our near future will include
the much-talked-about Web services supported by UDDI, SOAP, and XML. Beyond that, Waldo
sees Jini technology as being best equipped to support interacting networks. In his crystal ball, he
does see a technology beyond Jini -- he's just not sure what it is. The network: A look at where we are
Waldo, chief architect for Jini technology, pointed out that even though Sun first began
saying "The network is the computer" back in 1986, many people -- both inside and outside of
Sun -- weren't quite sure what that meant. He reviewed the ISO seven layers and noted that there is agreement on the Network and Transport layers. IP is pervasive and plenty of people are making money on it, so he doesn't see IP going away. "IP," said Waldo," is just the dial tone. The frontier is at the presentation and
session layers. We need to consider how you dial and how you talk once you are connected."
The technologies most associated with these layers include XML, COM+, RMI, CORBA, and XDR over
RPC. Waldo doesn't suggest that one technology is better than another, but rather
"which one people use depends on what they're trying to do." In each case, the idea is
to let one computer take information of various forms and pass this data on to another
computer. These technologies accomplish this task in different ways that affect what you can do. Waldo believes that, unfortunately, "human beings remain an integral peripheral" in this process. But what happens when there are so many more computers than people that you can't possibly have humans involved in these inter-computer communications? To remove people from this process, we need to allow ad hoc interaction between machines. For this to happen we need to consider which tasks are best performed by humans and which are best performed by machines. One of the stumbling blocks here is that computers are bad at names. When I make a mistake in typing a "worrd", you know immediately that I meant to type "word" -- this is a human strength, not a machine strength.
Platform evolution
Before looking forward, Waldo looked back at the evolution of the computing platform.
Although we progressed in discrete steps, there is much overlap. People don't stop using old technologies
just because new ones have arrived. After the client/server model, came the three- or N-tier platform, in which CORBA was used to introduce objects for the structure within a network. Currently, we work with Internet applications, in which we consider only a single network and work with technologies like CORBA and RMI. The next step is a big one: networks talking to other networks to offer services. We are hearing a lot about that now with technologies like UDDI, SOAP, and XML. The emphasis is on Internet services and cautious interactions with other, trusted, networks. Waldo uses an analogy of American/Russian relations in the 1950s to simplify: "the consequence of screwing up opens your enterprise to the competition." We are surrounded by computers that don't look like computers anymore. When you look at your microwave do you see a computer? When you look at your
car do you see a network? When you look at an MP3 player do you see a file server?
We need to think about these computers as they begin to communicate. As Waldo noted,
you certainly wouldn't want a "Melissa virus attacking your anti-lock brakes."
Waldo sees Jini as the next logical step, with its ability to deliver services in a network and allow for spontaneous interaction between programs that use these services. It's interesting to note that Jini was invented before Internet services, but Waldo thinks it is still the obvious next step. Connectivity is growing as a cube, not as a square, and it can easily swamp our computation power. Going back to his Cold War analogy, he sees current interaction between networks as being very stylized. In the future, this can't be the case;
we can no longer assume that a person is in the loop. Part of the strength of Jini is that it begins to deal with a network that is unknowable and unplannable. He sees Jini as having the ability to deal with the idea that "every point on network is an edge." This concept encompasses two things: every point is a possible entry point to the network, and each point has pressure to decompose into smaller components, which then collaborate to provide the same service and more.
 |
Ideas behind Jini
Waldo's description of Jini is simple: "Jini is designed so that chunks of code can
find other chunks of code without people." Keeping Jini's design simple, however, was one
of his hardest tasks. Another difficulty was getting people to deal with the realities of
a network instead of widely held beliefs. Jini was designed assuming that the network is
not reliable. Things join the network and leave the network. There is no central control. Also, Jini blurs the
distinction between hardware and software, dealing only with services. Because Jini is built on top of the Java platform, you can take advantage of types in interesting
ways. Types are a rich way for machines (not people) to view the world. Waldo offers an
example of an application looking for a printer. A color printer may be a subtype of
printer and so it can respond. If your application is smart enough, it can use reflection to discover if the printer has this additional functionality and take advantage of it. This use of polymorphism helps us deal with technological evolution in robust ways by using upwardly compatible subclassing. Jini is built on top of the RMI design semantic. Stub code is dynamically loaded from a service and has the same type as what it represents. What you get back in Jini is a representative of the service that handles the interface to the service. After you get this representative, you can find out what the service can do. This approach also explains why Jini is protocol-independent: the communication happens between the representative and the service.
Where is Jini going?
Waldo noted that Sun thought that the Java platform would find its strength on the client,
and that it has instead been most successful on the server. Although many of the Jini engineers
have anticipated the directions that the technology has taken, they have less knowledge of the
applications of the technology. As Waldo noted, Jini is free under a "don't mess things up"
license, so Sun often doesn't know how people are applying their work. Waldo cited several unexpected uses of Jini:
- It's being used to turn a large network of low functioning computers into a supercomputer
to perform impressive calculations.
- An online securities trading firm is using Jini to address load management by using
JavaSpaces to find out what they were supposed to be doing next.
- The U.S. Army is using Jini to re-establish networks in rapid deployment of forces, and
the U.S. Navy is using Jini on a Super Stealth Destroyer to have "vital services" look at a
"threat assessment service" to protect various systems.
So do you need a desktop or server running the Java platform to be running Jini? The surprising answer
is no. Waldo explains that you need only one Java-capable, non-memory-limited device on
the network. A resource-limited device can use the surrogate approach. Instead of that
device moving services in by getting a proxy to the service, it creates a proxy to itself. The device then moves the proxy onto the network to a machine that performs the service and then passes it back to the
original device. Objects are still moving over the network; all that has changed is
the direction.
Summary
Jim Waldo said that in 1991, when he was done working with CORBA, he thought that would
be the end of his interest in distributed computing; that he would have to find another area
of research. Ten years later he is excited about the wealth of problems yet to investigate.
He delights in the things that he doesn't know and the contributions of the Jini community
to this endeavor. He envisions something beyond Jini, but feels that this is the right step
based on what we know now.
Resources
About the author  | 
| | Daniel is the co-author of the
Java 2 Bible
and is a Java trainer and consultant for Dim Sum Thinking. He spends as much time as possible with Kimmy the wonderwife and their two daughters. Late at night when his family falls asleep, he sneaks back to his computer to write books and articles about Java programming and industry news. His hobbies include cooking with his daughters and Java development for Mac OS X. Contact Daniel at DSteinberg@core.com. |
Rate this page
| 
