Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
-- Antoine de Saint-Exupery
The Jini architecture is designed for deploying and using services in a network. Networks are by nature dynamic: new things are added, old things are removed, existing things are changed, and parts of the network fail and are repaired. There are therefore problems unlike any that will appear in a single process or even multiple processes in a single machine.
These differences require an approach that takes them into account, makes changes apparent, and allows older parts to work with newer parts that are added. A distributed system must adapt as the network changes since the network will change. The Jini architecture is designed to be adaptable.
This book contains three parts. The first part gives an overview of the Jini architecture, its design philosophy, and its application. This overview sets up the following sections, which contain examples of programming in a Jini system. The first section of the introduction is also usable as a high-level overview for technical managers.
The sections of the introduction that contain examples are designed to orient you within the Jini technology and architecture. They are not a full tutorial: Think of them as a tour through the process of design and implementation in a Jini system. As with any tour, you can get the flavor of how things work and where you can start your own investigation.
The second part of the book is the specification itself. Each chapter of the specification has a brief introduction describing its place in the overall architecture.
The third part of the book contains supplementary material: a glossary that defines terms used in the specifications and in talking about Jini architecture, design, and technology, and two appendices. Appendix A is a reprint of "A Note on Distributed Computing," which describes critical differences between local and remote programming. Appendix B contains the full source code for the examples in the introductory material. History
The Jini architecture is the result of a rather extraordinary string of events. But then almost everything is. The capriciousness of life--and to the fortunate, its occasional serendipity--is always extraordinary. It is only in retrospect that we examine the causes and antecedents of something interesting and decide that, because they shaped that interesting result, we will call them "extraordinary." Other events, however remarkable, go unremarked because they are unexamined. Those of us who wrote the Jini architecture, along with the many who contributed to its growth, are lucky to have a reason to examine our particular history to notice its pleasures.
This is not the proper place for a long history of the project, but it seems appropriate to give a brief summary of the highlights. The project had its origins in Sun Microsystems Laboratories, where Jim Waldo ran the Large Scale Distribution research project. Jim Waldo and Ken Arnold had previously been involved with the Object Management Group's first CORBA specification while working for Hewlett-Packard. Jim brought that experience and a long-term background in distributed computing with him to Sun Labs.
Soon after joining the Labs, Jim made Ann Wollrath part of the team. Soon after, observations about many common approaches in the field of distributed computing led Jim, Ann, and the other authors to write "A Note on Distributed Computing," which outlined core distinctions between local and distributed design. Many people had been trying to hide those differences under the general rubric of "local/remote transparency." The "Note" argued that this was not possible. It has become the most cited Sun Laboratories technical report, and the lessons it distills are at the core of the design approach taken by the project.
At this time the project was using Modula 3 Network Objects for experiments in distributed computing. As Modula 3 ceased to be developed, the team looked around for a replacement language. At that time Oak, the language an internal Sun project, seemed a viable replacement with some interesting new properties. To a research project, the fact that Oak was commercially insignificant was irrelevant. It was at this time that Ken rejoined Jim on his new team.
Soon after, Oak was renamed "Java."
When it was still Oak, it once had a remote method invocation mechanism, but that was removed when the mechanism failed--it, too, had fallen into the local/remote transparency trap. When Bill Joy and James Gosling wanted to create a working distributed computing mechanism, they asked Jim to lead the effort, which switched our team from the laboratories into the JavaSoft product group. As the first result of this effort, Ann, as the Java RMI architect, steered the team on an exploration of what could be done with a language-centric approach to distributed computing (most distributed computing systems are built on language-neutral approaches).
After RMI became part of the Java platform, Bill Joy asked the team to expand its horizons to include a platform for easier distributed computing, coining the name "Jini."1 He convinced Sun management to put the RMI and Jini project into a separate unit. This new unit started with Jim, Ann, Ken, and Peter Jones, and was soon joined by Bob Scheiffler who had extensive distributed computing experience from the X Windows project that he ran. This put together the original core architectural team: Jim, Ann, Ken, and Bob.
As the team grew, many people had a hand in the direction of various parts of the architecture, including Bryan O'Sullivan who took over the design of the lookup discovery protocol. Mike Clary took the project under his wing to give it time to grow. Mark Hodapp joined the team to manage its software development and run it in partnership with its technical leadership. Gary Holness, Zane Pan, Brian Murphy, John McClain, and Bob Resendes all reviewed the primary architecture documents and had responsibility for various parts of the tool design, implementation design, and the implementations themselves. Laird Dornin and Adrian Colley joined the RMI sub-team to continue and expand its development. Charlie Lamb joined the architectural team to oversee work with outside companies, starting with printing and storage service standards. Jen McGinn joined the team to document what we had done, later with the help of Susan Snyder on production support. Jimmy Torres started out as our release engineer and has changed to working on helping build our public developer community. Frank Barnaby took over the release engineering duties. Helen Leary joined early and kept our infrastructure humming along.
Our QA team was Mark Schuldenfrei and Anand Dhingra, managed by Brendan Daly. Alan Mortensen wrote the conformance tests and their infrastructure. Emily Suter and Theresa Lanowitz started out our marketing team, with Franc Romano, Donna Michael, Joan MacEachern, and Paula Kozak joining later. Jim Hurley started setting up our support organization, and Keith Thompson and Peter Marks joined to work on sales engineering. Samir Mitra led a marketing and business development team that included Jon Bostrom, Jaclyn Dahlby, Mike McNerny, Miko Matsamura, Darryl Mocek, Sharam Moradpour, and Vince Vasquez. Many others, too numerous to mention, did important work that made the Jini architecture possible and real. Acknowledgments
As the specifications were written, almost every member of the team made important contributions. Their names are listed above; we note the fact here to express our gratitude. A good idea and a dollar will buy a bad cup of espresso--you need people who will make that idea live, sand off any rough edges, and help you rework any bad parts of the idea into good ones. We had those people--some of the best we've ever worked with. Without them the Jini architecture would be some rather nice ideas on paper. Because of their commitment to adopt the vision as their own, to make it better, and to make it real, there are people (like you, the reader) who care about these ideas and can do something with them. We thank the entire team for what they have done to improve the Jini architecture and to help us write and release the Jini technology.
Bill Joy created the environment in which the Jini architecture could be developed and nurtured, and fed the architecture with his own reviews and ideas. His vision and support inside and outside of Sun made the project possible. This book itself is also his idea.
Bob Sproull gave the Large Scale Distribution project scope and support that has continued to this day, through all its many twists and turns, even after we were no longer were part of his Sun Labs organization. Mike Clary's protection and guidance was critical to fostering the creative atmosphere around the Jini project.
Jen McGinn and Susan Snyder did a lot of work to make this book possible, including hours in front of a screen converting the specification documents from their original form into that of the book. Jen also worked hard to improve the content of the specifications and introductory material during their creation, making them clearer and their English more correct. Dick Gabriel contributed to the content and organization of the Jini Architecture Specification, making it clearer and easier to use.
Many people reviewed the introductory material, making comments that improved it tremendously: Liz Blair, Charlie Lamb, John McClain, Bob Resendes, and Bob Sproull. Lisa Friendly has applied her experience as series editor with the Java Series to help us create this sibling Jini Series. We would also like to thank the people at Addison-Wesley's Professional Computing group who worked with us on this book and the series: Mike Hendrickson, Julie DeBaggis, Sarah Weaver, Marina Lang, and Diane Freed. And without Susan Stambaugh's help, communicating with Bill (and sometimes Mike) is not merely difficult, but probably theoretically impossible.
To these and many others too numerous to mention we give our thanks and appreciation for what they did to make these ideas and this book possible.
------------------------------------------------------------------------
1. Jini is not an acronym. To remember this, think of it as standing for "Jini Is Not Initials." It is pronounced the same as "genie."
0201616343P04062001
Foreword The emergence of the Internet has led computing into a new era. It is no longer what your computer can do that matters. Instead, your computer can have access to the power of everything that is connected to the network: The Network is the Computer(tm). This network of devices and services is the computing environment of the future.
The Java programming language brought reliable object-oriented programs to the net. The power of the Java platform is its simplicity, which allows programmers to be fully fluent in the language. This simplicity allows debugged Java programs to be written in about a quarter the time it takes to write programs in C++. We believe that use of the Java platform is the key to the emergence of a "best practices" discipline in software construction, to give us the reliability we need in our software systems as they become more and more widely used.
The Jini architecture is designed to bring reliability and simplicity to the con-struction of networked devices and services. The philosophy behind Jini is language-based systems: a Jini system is a collection of interacting Java programs, and you can understand the behavior of this Jini system completely by under-standing the semantics of the Java programming language and the nature of the network, namely that networks have limited bandwidth, inherent latency, and partial failure.
Because the Jini architecture focuses on a few simple principles we can teach Java language programmers the full power of the Jini technology in a few days. To do this we introduce remote objects (they just throw a RemoteException), leasing (commitments in a Jini system are of limited duration), distributed events (in the network events aren't as predictable on a single machine), and the need for two-phase commit (because the network is a world of partial failures). This small set of additional concepts allows distributed applications to be written, and we can illustrate this with the JavaSpaces service, which is also specified here.
For me, the Jini architecture represents the results of almost 20 years of yearning for a new substrate for distributed computing. Ever since I shipped the first widely used implementation of TCP/IP with the Berkeley UNIX system, I have wanted to raise the level of discourse on the network from the bits and bytes of TCP/IP to the level of objects. Objects have the enormous advantage of combin-ing the data with the code, greatly improving the reliability and integrity of sys-tems. For me, the Jini architecture represents the culmination of this dream.
I would like to thank the entire Jini team for their continuing hard work and commitment. I would especially like to thank my long time collaborator Mike Clary for helping to get the Jini project started and for directing the project; the Jini architects Jim Waldo, Ken Arnold, Bob Scheiffler, and Ann Wollrath for designing and implementing such a simple and elegant system; Mark Hodapp for his excellent engineering management; and Samir Mitra, for committing early to the Jini project, helping us understand how to explain it and what problems it would solve, and for driving the key business development that helped give Jini technology the momentum it has in the marketplace today. I would also like to thank Mark Tolliver, the head of the Consumer and Embedded division, which the Jini project became part of, for his support.
Finally, I would like to thank Scott McNealy, with me a founder of Sun and its longtime CEO. It is his continuing support for breakthrough technologies like Java and Jini that makes them possible. As Machiavelli noted, it is hard to intro-duce new ideas, and support like Scott's is essential to our continuing success.
Bill Joy
Aspen, Colorado
April, 1999
