Jean Dollimore

The design of a system for distributing shared objects

The primary motivation for the work described in this paper is to design 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 example applications a departmental database, a room booking program and a shared spreadsheet.

PerDiS: Design, Implementation, and Use of a PERsistent DIstributed Store

The PerDis (Persisent Distributed Store) project addresses the issue of providing support for distributed collaborative engineering applications. We describe the design and implementation of the PerDis platform, and its support for such applications. Collaborative engineering raises system issues related to the sharing of large volumes of fine-grain, complex objects across wide-area networks and administrative boundaries. PerDiS manages all these aspects in a well defined, integrated, and automatic way. Distributed application programming is simplified because it uses the same memory abstraction as in the centralized case. Porting an existing centralized program written in C or C++ is usually a matter of a few, well-isolated changes. We present some performance results from a proof-of-concept platform that runs a number of small, but real, distributed applications on Unix and Windows NT. These confirm that the PerDiS abstraction is well adapted to the targeted application area and that the overall performance is promising compared to alternative approaches.

Sharing objects over the Internet: the Mushroom approach

This paper reports on the Mushroom project. The project is developing a software framework for collaborative working and user interaction on the Internet. The paper illustrates some of the required features in the context of an application scenario and outlines those aspects of the Mushroom system architecture that support the sharing of information. The projects motivation is to address the problems of coordinated user interaction, distribution and privacy. Mrooms are interactive environments for groups of collaborating users. They provide a shared space in which users are aware of one another while working on shared objects. Their boundaries provide a triggering mechanism for consistency and privacy checks. In contrast to other systems with room-based metaphors, Mushroom focuses on a scalable and flexible system architecture using replicated state, group communication and event-based updates.

Role and task-based access control in the PerDiS groupware platform

A roleand task-based access control scheme has been developed for use in a class of activities that entail cooperation between principals in a virtual enterprise (VE). Data ownership is associated with the component organisations of a VE, each of which constitutes a trust domain. The role/task model was chosen to meet the requirement for a generic access control scheme independent of application code. The model has been implemented for a software platform that provides shared access to clusters of replicated distributed objects. Implications arising from the integration of the access control model with a data replication scheme are discussed.

Secure Communication in Non-uniform Trust Environments

Islands of trust arise in the Internet because trust in computer systems and their software is largely based on confidence in the local administrators of systems and their managers. Each such region of local trust often corresponds to a corporate Intranet.

A model for co-operative object-oriented programming

In this paper we describe an abstract model for the development of object-oriented software in a context where several programmers work together as a team. We introduce the different levels that compose our model, mapping its concepts and tools to existing systems whenever possible. The goal of this work is to design an environment for co-operative programming that deals specifically with the needs of developers using object-oriented technology. Our model is based on existing software engineering tools for the development of medium and large software projects, and also on a survey of user requirements for object-oriented programming. We explain the reasons why existing software engineering tools for team programming are not suited to object-oriented technology. We also briefly describe our prototype and the tools necessary to support our co-operative object-oriented programming model.

The relevance of object groups and multicast shared distributed object systems

We argue that object groups and multicast invocations are very useful in the construction of an object based platform for building multi-user applications. We illustrate our argument with reference to three aspects of our design. The first aspect relates to the issue of informing users when other users have altered shared objects. The second aspect concerns the design of an optimistic form of concurrency control for replicas of shared objects. The third aspect is a suggested solution to the problem of distributing capabilities to groups of users. Our conclusion is that, although ordered multicast is essential for some purposes, reliable and even unreliable multicast are also very useful in contexts requiring object group invocations.

Fault tolerance with shared objects and nested transactions

We will discuss our experience in designing a distributed object-based system as a part of the Esprit SPIRIT project. We are designing a system that supports distributed objects that can communicate with one another by the use of transparent remote invocations and replies. Selected objects in our system may be declared to be persistent, in which case they will be recoverable and may participate in nested atomic transactions. Users will possess their own private objects and may in addition have access to some objects they share with other users. Any object that is available for remote invocation may be shared. We are investigating the problems that arise when a single user application is made into a shared distributed application. Our first example is a simple room booking program which we use as an illustration here. The room booking program has a collection of buildings, within each building is a collection of rooms and each room has a diary containing a set of bookings. A booking consists of start time, finish time and description. Buildings, rooms, diaries and bookings are all separate independent persistent objects. In the distributed version of this application, the persistent objects will typically be distributed over several different computers and accessed via user interfaces in users workstations as in Figure 1.