As a software development manager in a prior life, I had a splendid vantage point from which to observe the daily dramas of cubicle land. The parcel of that peculiar terrain in our office divided equally between system administrators and developers. With time, these two groups came to represent the antagonistic forces whose occasional clashes would punctuate our daily lives.

The system administrators, in their earnest quest to create order in the server room, would change some aspect of the network environment. Soon enough, our support desk would become inundated with phone calls signaling one or another server being "down." Chewing gum and bailing wire in hand, the administrators would then mount a heroic effort to restore the faulty service. Their triumph would always end with the claim that the whole affair rested with the developers' guilt, since it was their "system" that proved too fragile. The developers would then claim the contrary: If only administrators stopped reconfiguring the network... There had to be a better way.

And there was. By some force of serendipity, I came upon an article co-authored by Jim Waldo, who at that time headed up the Jini project at Sun. The effect of A Note on Distributed Computing was similar to discovering another person's footsteps in a supposedly deserted island: So I was not alone in facing those problems! The Note's bitter message, however, quickly dissipated my relief: Get over it. Failure is inevitable. Change is constant. You might as well learn to live with the exigencies of the network.

Of course, the network is not only, or even primarily, a source of failure and chaos: The network is also a source of tremendous opportunity. Indeed, because of that opportunity, and in spite of its pitfalls, networks have, over the past decade, grown in both size and in the way their deliver their value. In the process, our very notion of designing and constructing computing systems has changed.

A "system" used to mean a harmonious co-existence of things, designed and engineered to work well together. In most other fields of human endeavor, a system still evokes that connotation: When you consider a car, an airplane, or a house, or even a system of government, you have in mind an orderly arrangement of parts all designed in advance to smoothly work together.

Network computing also fit that description—up to a few years ago. Network protocols, communication infrastructure, and software applications, were all designed with an orderly arrangement of things in mind. With time, however, our desire for order came to be challenged by the cavernous seduction of Metcalf's dictum: That the value of the network increases exponentially with the number of hosts it connects. Today, most interesting and valuable computing systems are those that thrive on ever larger networks.

But pursuing the value of increasingly large networks has magnified the "fallacies of the network" that Peter Deutsch has so aptly summarized. Certainly, the network is not reliable, at least not all the time: large numbers of hosts connected shifts the chance of failure from probability to certainty. While not outright failure, latency always rears its head. Bandwidth varies widely, decreasing sharply and becoming asymmetrical towards the network's edges. Size introduces so many network participants that security and trust can no longer be assumed. While we have mostly outgrown our obsession over topology—or "topomania" in the words of Gordon Bell—networks are increasingly partitioned around administrative and security domains. And, of course, all those network partitions have their own administrators. Connecting all things has also increased the desire to transmit more things—and transmission costs, both in economic and in networking terms, will likely outpace that increased desire. Finally, connecting many things also means connecting many kinds of things, in many kinds of ways—so long, homogeneity.

Deutsch's "fallacies" have become today's realities. Because most interesting computing systems live on large networks, these new realities have become the chief concerns of designing and building computing systems today.

Beyond spurring the development of new technologies, these realities have also resulted in the recognition of a more fundamental truth: That successful system designs must consider change in the network as its chief premise—that spontaneity is a primary element in today's systems, and that constancy is rare.

This Journal is about that spontaneous element in networks. You can expect on these pages articles on specific technologies that embrace spontaneity, such as Jini, Bluetooth, Rendezvous, JXTA, or UPnP. You will also find articles that illuminate some aspect of spontaneous networking from the vantage point of many technologies. We want to be practical so that knowledge you gain from this Journal will quickly make your job easier. We also wish to bring communities formed around the various spontaneous networking technologies together so that we can all share our experiences and what they taught us. Most of all, we would like to become the forum where the various communities ask the tough questions from one another, and where the answers will then lead to even better questions. Thus, instead of asking why the programmers are not doing better, or why the system administrators are always at fault, we can find ways to do a better job altogether.

I would like to thank the editorial advisory board for so graciously agreeing to participate and provide valuable input into forming the subject matter of this Journal.

I would also like to take this opportunity to invite you, the reader, to become a contributor to our Journal. The Journal of Spontaneous Networking is peer-reviewed, and as an author you will find a prestigious and fair forum for sharing your ideas. Please see the write for us page for more details on contributing.

Talk back!

Have an opinion? Readers have already posted 1 comment about this article. Why not add yours?

About the author

Frank Sommers is founder and CEO of Autospaces, a company dedicated to bringing Web services and Jini to the automotive sales and finance industries. He also writes Javaworld's Web services and Jiniology columns, and serves as chief editor of ClusterComputing.org, the Newsletter of the IEEE Task Force on Cluster Computing. Frank is Artima.com's Web Services columnist.