Matthew Fuchs, PhD Walt Disney Imagineering 1401 Flower St. POB 25020 Glendale, CA 91221-5020 matt@wdi.disney.com Title: How do we know what's really going on? With several years experience and the development of several systems, such as Emerald, Obliq, and my own Dreme, it is now obvious that object mobility, per se, is not a complicated task. The complexity all resides in choosing a semantics. My own work with mobile objects centers on the development of Dreme, a distributed dialect of Scheme in which all first-class objects are mobile over the network. Dreme extends three of Scheme's most powerful abstractions over the network to support mobile distributed communications (this work was done in '92-93): 1) Nested lexical scoping. This provided a means to ensure correct communication within a mobile application, despite movement. Once an object was known, the run-time system could always find it again. 2) First class functions (which together allow closures) provided a powerful and flexible way to group objects that was at least as powerful as objects (and which I could eventually use to express any object system I desired). An applications could use closures to organize objects together and then place them around the network as desired. Clients and servers are just nested higher order functions. 3) Continuations. Just as ordinary continuations can be used to implement any traditional control construct, distributed continuations can do the same for distributed/parallel constructs, such as guardians and select statements. However, using continuations meant I was not restricted to any preordained set of constructs, but could build new ones as needed. A large part of the goal of Dreme was to show that mobile distributed systems could be built from these abstractions (with the addition of an atomic blocking mechanism, such as monitors). In Dreme, mobile distributed applications can be written at the command line and objects queried interactively. I intentionally eschewed an "object-oriented approach" (i.e., explicit class definitions, inheritance, and method invocation) because I felt it was not yet obvious what these should be in a system of mobile distributed objects. It is the purpose of experimentation to determine these things. The building blocks I chose (a distributed lambda calculus) could be used to build and test any conceivable distributed object system. At this point I would advocate the development of a "mobility and distributed communication" abstract machine which could be used as the basis for building higher-level constructs such as object systems for mobile objects - essentially a location-aware denotational semantics, based on the untyped lambda calculus. This would provide a way to describe, compare, and test various ways of combining issues such as mobility and replication with object systems in a more systematic way than just arguing our intuitions. For example, object-systems have generally broken down between message-based systems, where encapsulation closely binds data and procedure, and generic function-based systems, where they are split. The Lisp community appears to have gone with the latter choice, while the rest of the object community has gone with the former. At first glance, generic functions appear ill-suited to distributed systems where the different nodes have developed independently. If the parameter objects reside at different locations, each with different generic functions, it is not immediately obvious which code to invoke as there are arguments in favor of all the alternatives. However, if we consider a generic function as another object, then the name is bound to a (possibly mobile) location, and the problem resolves itself. In fact, it is really an issue of scoping rules - generic systems generally have a hidden assumption that generic functions are of global scope. In a related fashion, Jim Waldo has pointed out the problems of ignoring the complex failure modes of networks, but has not given much guidance on how object systems can better support this through inheritance of other mechanisms. And we must also consider what should happen to objects and communications as the pass through different realms of trust. With these complex issues, where such a seemingly simple act as sending a message may involve an unknown number of intermediaries, it is not even obvious to which object to turn for ensuring some constraint. Mobile objects, in one form or another, are starting to break out of the research community and will be expected to be reliable. Before we let them completely loose we should take a careful, and rigorous, look at what they will be doing.