The Design of a System for Distributing Shared Objects

The Design of a System for Distributing Shared Objects* J. DOLLIMORE,t E. MIRANDA AND WANG XU Department of Computer Science, Queen Mary and Westfield College, Mile End Road, London El 4NS The primary motivation for the work described in this paper is the design of a platform for building applications that are intended for use by a group of people. The paper introduces the requirements for applications in which people use workstations on a local area network to share information and to communicate with one another. The paper discusses how we addressed these requirements in the context of three sample applications — a departmental database, a roombooking program and a shared spreadsheet. 1. INTRODUCTION This paper discusses the design and implementation of a distributed object-oriented programming environment. Our motivation for designing this environment is to provide a platform for building applications that are intended to be used by a group of people who would like to use computers for communication and sharing information. We assume that users have access to workstations connected to a local area network. The type of application we have in mind is illustrated by the following examples: • simple shared databases, e.g. address lists, information about people in a department; • shared diaries and booking systems; • shared spreadsheets. user editing systems such as ShrEdit14 and the multi-user drawing program described by Hagsund.9 Our main design goals relating to the support of shared applications are to be able to: • share data that is inherently distributed; • support user interfaces that are appropriate for shared information and have acceptable performance. 2. REQUIREMENTS We have identified the following requirements for a programming system that provides a platform for building distributed applications for workstation users on a local area network: it must be possible to place shared objects in any computer that runs our software - this may be in a user's workstation or in a server; in addition it should be easy to make objects available for sharing; (ii) location and access transparency - the application builder should be able to design application software without concern as to the location of the objects accessed; (iii) information should be presented to users through an interactive user interface allowing them to view and manipulate the information as easily as in today's single-user applications; a side effect of this requirement is the need to place replicas of shared objects in users' workstations; (iv) several people must be able to view and edit the same objects simultaneously and observe one another's effects; (v) when objects are accessed by more than one person at a time, the overall effects should be consistent; (vi) privacy and protection of information - unauthorised users must be prevented from seeing or altering objects that they are not intended to use in that way; (vii) long-term reliable storage of objects is required this requires a mechanism for transparent persistency in which certain objects are automatically preserved for as long as they are needed. (i) Such applications are characterised primarily by supporting information that is shared by the members of a group. Their secondary characteristic is that each application allows users to manipulate quite complex information structures. We use the term object* to refer to a unit of information within an application, such as a week in a diary or a cell in a spreadsheet. We note that objects belonging to a particular application generally contain connections to other objects; for example, a spreadsheet cell can contain a reference to the objects containing its value and its formula. We make no assumption as to whether users access objects at the same time as one another or at different times. In the case of shared databases, users will access objects whenever they require them and will add new information whenever it becomes available. The fact that more than one user may access the same object simultaneously is generally of no importance to the users involved except in so far as it may cause conflict. When users choose to access a set of objects simultaneously, each user can have an independent view of the information. Although the views of different users may overlap in that both contain some of the same objects, there is no assumption that they would share a view. However, this does not prevent users from having the same views as one another, as for example in multi* This work is supported by the Esprit SPIRIT High Performance Workstation project. t To whom correspondence should be addressed. * It will become apparent in a later section that the notion of object also includes operations. Our requirements and the experience described by other researchers has led us to choose an object-oriented programming environment. The object model has been 514 THE COMPUTER JOURNAL, VOL. 34, NO. 6, 1991 Received May 1991, revised July 1991 THE DESIGN OF A SYSTEM FOR DISTRIBUTING SHARED OBJECTS 3. REMOTE INVOCATION OF THE METHODS IN OBJECTS In Smalltalk, all entities are represented by objects that encapsulate a set of methods and private states. All computation proceeds by sending a message to some object which invokes a method which may in turn send further messages. The only direct access to an object's state is through manipulations by one of that object's methods. We can distinguish between mutable objects, which are objects that provide methods that alter their state, and immutable objects which do not. Once an immutable object has been initialised it will never change its state. Immutable objects include integers, characters and boolean values. Transparent remote method invocation allows an object to send a message to any other object and to receive a reply without being aware of whether the receiver is local or remote. Transparency is achieved by automatically providing a local proxy for each remote object that can be invoked by a local object.4 The function of a proxy is to behave like a local object towards the message sender, but instead of executing the message, it forwards it to the process (in another computer) where the remote object is located. The remote object performs the message and replies without being aware that its reply is sent back to a sender on a remote computer. Every object in Smalltalk has a local identifier (or object reference)* that is valid within a single Smalltalk process. In our system any object that is to be referenced by an object in another computer is given a globally unique object identifier. This global identifier is generated at the object's local computer the first time its local identifier is to be sent to another computer in a reply to a message, in which case the global identifier is sent in place of the local identifier. The forwarding mechanism and the marshalling of messages is described in detail in Ref. 16, in which performance figure (...truncated)