An Overview of the Design of Distributed Oz

Seif Haridi

Swedish Institute of Computer Science (SICS), Sweden

seif@sics.se

Peter Van Roy

Universit?e catholique de Louvain (UCL), Belgium

pvr@info.ucl.ac.be

Gert Smolka

Universit?at des Saarlandes, Saarbr?ucken, Germany

smolka@ps.uni-sb.de

Abstract

We present a design for a distributed programming system, Distributed Oz, that abstracts away the network. This means that all network operations are invoked implicitly by the system as an incidental result of using particular language constructs. However, since network operations are expensive, the programmer must retain control over network communication patterns. This control is provided through the language constructs. While retaining their centralized semantics, they are extended with a distributed semantics. Distributed Oz is an extension of Oz, a concurrent state-aware language with first-class procedures. Distributed Oz extends Oz with just two concepts: mobility control and asynchronous ordered communication. Mobility control provides for truly mobile objects in a simple and clean way. Asynchronous ordered communication allows to conveniently build servers. These two concepts give the programmer a control over network communications that is both simple and predictable. We give scenarios to show how common distributed programming tasks can be implemented efficiently. There are two reasons for the simplicity of Distributed Oz. First, Oz has a simple formal semantics. Second, the distributed extension is built using network protocols that are natural extensions to the centralized language operations. We discuss the operational semantics of Oz and Distributed Oz and the architecture of the distributed implementation. We give an overview of the basic network protocols for communication and mobility.

Keywords. Language-based Distribution, Mobile Objects, Network Transparency, Semantics, Implementation, Concurrent Constraints

1 Introduction

The number of computers in the world and their interconnectedness both continue to increase at an exponential rate [17]. This leads one to predict that eventually most applications will run across a network, i.e., will be distributed. To manage the increasing complexity of application development, we propose that a long-term solution to distributed

programming must reduce its programming complexity to be comparable to centralized (i.e., non-distributed) programming. We propose to achieve this by designing and implementing a language, Distributed Oz, that abstracts away the network. All network operations are then invoked implicitly by the system. However, for efficiency the programmer should retain control over network communication patterns. In Distributed Oz there are no explicit operations (such as message sending or receiving) to transfer data. All network transfers are done implicitly through the same language constructs of centralized programming. In order for this to be practical, these language constructs must be extended to a distributed environment such that network communication patterns are clearly perceived by the programmer. For example, the language must give clear meanings to replicated data and mobile objects.

1.1 Extending the basic language operations

All systems that we know of except Obliq [3] and Emerald [13] do distributed execution by adding a distribution layer on top of an existing language [18, 26, 27, 30]. This has the disadvantage that distribution is not a seamless extension to the language, and therefore distributed extensions to language operations (such as mobile objects or replicated data) must be handled by explicit programmer effort. A better technique is to look carefully at the basic operations of the language and to conservatively extend them to a distributed setting. For example, the Remote Procedure Call (RPC) [26] is designed to mimic centralized procedure calling and is therefore a precursor to the design given in this paper. This second approach has two consequences. First, in order to carry it out successfully, the language must have a well-defined operational semantics that clearly identifies the basic operations and separates them from each other.

Second, to do the distributed extensions right one must design a network protocol for each basic operation of the language. Obliq has taken a first step towards this goal. Obliq distinguishes between values and locations. Moving values causes them to be copied (replicated) between sites. Moving locations causes network references to them to be created. Distributed Oz goes further towards this goal by taking this approach for the complete language. Distributed Oz