Jim Waldo Geoff Wyant Ann Wollrath Sam Kendall
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer beaware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure. We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the smallsize of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible. We conclude by discussing what is required of both systems-level and application-level programmers and designers if one is to take distribution seriously.
A Sun Microsystems, Inc. Business
M/S 29-01 2550 Garcia AvenueMountain View, CA 94043
email addresses: email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org
A Note on Distributed Computing
Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall
Sun Microsystems Laboratories 2550 Garcia Avenue Mountain View, CA 94043
Much of the current work in distributed,object-oriented systems is based on the assumption that objects form a single ontological class. This class consists of all entities that can be fully described by the speciﬁcation of the set of interfaces supported by the object and the semantics of the operations in those interfaces. The class includes objects that share a single address space, objects that are in separate address spaces on the samemachine, and objects that are in separate address spaces on different machines (with, perhaps, different architectures). On the view that all objects are essentially the same kind of entity, these differences in relative location are merely an aspect of the implementation of the object. Indeed, the location of an object may change over time, as an object migrates from one machine to another or theimplementation of the object changes. It is the thesis of this note that this uniﬁed view of objects is mistaken. There are fundamental differences between the interactions of distributed objects and the interactions of non-distributed objects. Further, work in distributed object-oriented systems that is based on a model that ignores or denies these differences is doomed to failure, and could easilylead to an industry-wide rejection of the notion of distributed object-based systems.
In what follows, we will talk about local and distributed computing. By local computing (local object invocation, etc.), we mean programs that are conﬁned to a single address space. In contrast, we will use the term distributed computing (remote object invocation, etc.) to refer to programs that make calls toother address spaces, possibly on another machine. In the case of distributed computing, nothing is known about the recipient of the call (other than that it supports a particular interface). For example, the client of such a distributed object does not know the hardware architecture on which the recipient of the call is running, or the language in which the recipient was implemented. Given theabove characterizations of “local” and “distributed” computing, the categories are not exhaustive. There is a middle ground, in which calls are made from one address space to another but in which some characteristics of the called object are known. An important class of this sort consists of calls from one address space to another on the same machine; we will discuss these later in the paper.