What is a distributed object?

Distributed objects may exist in several different forms: memory vs. disk, on my machine vs. yours, in C++ vs. Python. Furthermore, an object may change forms during its lifetime, and its lifetime may extend beyond the lifetime of any particular process or machine. Therefore, we need the following three services:
  1. Persistent, distributed naming

    Naming is important for sharing. Without URLs and the sharing they allow, we'd have to store the whole Web on our hard disk, and update it every second. Unfortunately, current languages only support naming in the form of pointers, which only make sense in the context of a particular process on a particular machine. We want to be able to name an object, no matter what form it has, and have that name continue to apply as it changes form.

  2. Migration

    Objects should be able to change form while preserving their identity. Unfortunately, current languages only support conversion through copying. This doesn't work with a bank account, which must have exactly one instantiation at any time. Imagine what would happen if I simply copied my account to another machine. The withdrawals I make on one machine would be invisible to the other machine, so suddenly I've doubled my money! With object migration, my account can move from machine to machine, based on who wants to use it, without destroying its semantics. This problem is closely related to cache coherence in shared-memory multiprocessors.

  3. Form-neutral Invocation

    To use an object, you must be able to call its methods, no matter what form it has or how it got there. Unfortunately, current languages require that the object, or at least a proxy for it, be in a native, proprietary representation for the object's methods to be called. Furthermore, this is always a memory-based per-process representation. This means that the creator and user of an object must be the same process, and that an object's lifetime cannot extend beyond the creator process. A preferable, form-neutral invocation scheme can be implemented by either (1) designing it into the language or (2) exposing the native object representation, allowing anyone to write converters and proxies for it.

An infrastructure which provides these services is called a distributed object manager. Ideally, this should be part of the language. But since current languages were not designed with this concept, we must patch them with wrappers and proxies. Microsoft's COM and Taligent's CommonPoint provide such object management for C++. IBM's SOM , based on CORBA , provides object management for C++ and Smalltalk. ILU is a free object manager from Xerox PARC, minus a migration service, which supports C++, C, Smalltalk, Lisp, and Python.

Thomas Minka
Last modified: Thu Mar 9 14:23:47 EST 2000