transaction management support for cooperative applications

TRANSACTION MANAGEMENT SUPPORT

FOR COOPERATIVE APPLICATIONS

THE KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE


FOR COOPERATlVE APPLICATIONS

edited by

Rolf A. de By International Institute tor

Aerospace Survey and Earth Sciences The Netherlands

Wolfgang K1as University 0/ Ulm

Germany

Jari Veijalainen University 0/ Jyväskylä

Finland

SPRINGER SCIENCE+BUSINESS MEDIA, LLC

Library of Congress Cataloging-in-Publication Data

A C.I.P. Catalogue record for this book is available from the Library of Congress.

ISBN 978-1-4613-7600-2 ISBN 978-1-4615-5679-4 (eBook) DOI 10.1007/978-1-4615-5679-4

Copyright © 1998 by Springer Science+Business Media New York

Originally published by Kluwer Academic Publishers in 1998 Softcover reprint of the hardcover 1 st edition 1998

AII rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher, Springer Science+Business Media, LLC.

Printed on acid-free pa per.

CONTENTS

Contributing Authors ix

Foreword xi

Acknowledgments xiii

1 Introduction Wolfgang Klas, Rolf A. de By and Jari Veijalainen 1.1 Introduction 1 1.2 TransCoop Objectives 2 1.3 Application Requirements--The Driving Force Behind the Scene 4 1.4 Specification Language for Cooperative Transactions 6 1.5 Cooperative Transaction Model 6 1.6 Roots and Background of the Project 7 1. 7 Outline of the Book 8

2 The Transcoop Paradigm t 1 Jari Veijalainen, Rolf A. de By and Karl Aberer 2.1 Introduction 11 2.2 Motivation 12 2.3 Methodology Applied 13 2.4 Technical Prerequisites 15 2.5 Terminology and Central Notions 20 2.6 Positioning TransCoop Within the CSCW Field 23

3 Transaction Models in Cooperative Work--An Overview 27 Jari Veijalainen, Jurgen Wiisch, Juha Puustjiirvi, Henry Tirri and Olli Pihlajamaa 3.1 Introduction 27 3.2 A Brief History of the Term Transaction Model 28 3.3 Main Techniques to Implement the ACID Properties 38 3.4 Generalizing ACID 40 3.5 Advanced Transaction Models 48 3.6 What is a Transaction Model, What is a Transactional Framework? 57

v

vi

4 Application Requirements 59 Thomas Tesch, Peter Verkoulen, Aarno Lehtola, Jari Veijalainen, Olli Pihlajamaa and Aija Sladek 4.1 Introduction 59 4.2 Requirements from Workflow 61 4.3 Requirements from Design for Manufacturing 71 4.4 Requirements from Cooperative Document Authoring 80 4.5 Consolidated Requirements 85

5 The TransCoop Architecture 93 Aarno Lehtola, Rolf A. de By, Henry Tirri and Jurgen Wasch 5.1 Introduction 93 5.2 The TransCoop Reference Architecture 96 5.3 Comparison to Related Work 104 5.4 Implementation Choices and Discussion 111

6 The Transcoop Specification Environment 115 Frans J F aase, Susan Even and Rolf A. de By 6.1 Introduction 115 6.2 Requirements 117 6.3 A Cooperative Specification Language Paradigm 118 6.4 Example Cooperative Scenario 120 6.5 Definition of Organizational Aspects 123 6.6 Defmition of Transactional Aspects 128 6.7 Integration of Organizational and Transactional Aspects 132 6.8 The CoCoA Language 134 6.9 Reflections on the Formal Model of CoCoA 135 6.10 The CoCoA Tool Set 138 6.11 Related Work 138 6.12 Discussion 140 Appendix: The CoCoA Syntax 143

7 The TransCoop Transaction Model 149 Justus Klingemann, Thomas Tesch, Jurgen Wasch and Wolfgang Klas 7.1 Introduction 149 7.2 Overview of the CoAct Model 150 7.3 Cooperative Activities 153 7.4 Running Example 154 7.5 A Formal Model of History Merging 155 7.6 Discussion of Other Relations in the Context of CoAct 166 7.7 Summary 171

8 The TransCoop Demonstrator System 173 Justus Klingemann and Susan Even 8.1 Introduction 173 8.2 Overview 174 8.3 The Demonstrator Application 177 8.4 The Specification Environment 180 8.5 The Runtime Environment 184 8.6 Summary 191

9 Conclusions 193 Susan Even, Thomas Tesch and Jari Veijalainen 9.1 Reflections on the Cooperative Transaction Model 194 9.2 Implementation of Concepts 195 9.3 Critical Assessment 196 9.4 Extensions to the Specification Environment 197 9.5 Lessons for Transaction Management Research and Development 198

References 201

Index 217

vii

Contributing Authors

Karl Aberer GMD-IPSI, Darmstadt, Germany

Rolf A. de By International Institute for Aerospace Survey & Earth Sciences, lTC, Enschede, The Netherlands

Susan Even Department of Computer Science, University of Twente, Enschede, The Netherlands

Frans J. Faase Tecnomatix Machining Automation B.V., Enschede, The Netherlands

Wolfgang Klas Department of Computer Science, University of Ulm, Ulm, Germany

Justus Klingemann GMD-IPSI, Darmstadt, Germany

Aarno Lehtola VTT Information Technology, Information Systems, Espoo, Finland

OlIi Pihlajamaa VTT Information Technology, Multimedia, Espoo, Finland

ix

x TRANSACTION MANAGEMENT SUPPORT FOR COOPERATIVE APPLICATIONS

J uha Puustjarvi Department of Computer Science, University of Helsinki, Helsinki, Finland

Aija Sladek Senior Systems Analyst, Nokia Telecommunications, Nokia Group, Finland

Thomas Tesch GMD-IPSI, Darmstadt, Germany

Henry Tirri Department of Computer Science, University of Helsinki, Helsinki, Finland

Jari Veijalainen Department of Computer Science and Information Systems, University of Jyvaskyla, Jyvaskyla, Finland

Peter Verkoulen Origin IT Services B.V., Eindhoven, The Netherlands

J iirgen Wisch GMD-IPSI, Darmstadt, Germany

Foreword

Transaction Management Support for Cooperative Application is a comprehensive report on a successful international project, called TRANSCOOP, carried out from 1994 to 1997 by a group of European scientists. But the book is also much more than that, namely, an ambitious attempt to integrate Computer-Supported Cooperative Work (CSCW), Workflow Management Systems (WFMS), and Transaction Processing (TP) technologies.

The very term {\em cooperative transactions} is in itself contradictory. Cooperation technologies, such as CSCW, aim at providing a framework for information exchange between cooperating (human) participants. In contrast, traditional transaction technologies allow concurrent users to operate on shared data, while providing them with the illusion of complete isolation from each other. To overcome this contradiction, the TRANSCOOP researchers had to come up with a new and original notion of correctness of concurrent executions, based on controlled exchange of information between concurrent users.

Merging histories in accordance with prespecified commutativity rules among concurrent operations provides transactional guarantees to activities such as cooperative designing, which until now had to be carried out sequentially. As an interesting consequence, it also provides a basis for management of consistency between disconnected or mobile users who operate independently and yet, must occasionally reconcile their work with each other.

The theory and technology presented in this book are preceded by a rigorous analysis of requirements presented by diverse classes of cooperative applications, ranging from cooperative authoring, through design for manufacturing, to interorganizational workflows. Based on these requirements, the authors define a language that is suitable for the specification of cooperative activities. The language is based on a formal model and provides a collection of tools that allow the users to reason about the correctness of specifications, rather that relying on mechanisms that detect possible violations at run-time. The transaction model introduced in this book combines the use of private workspaces that allow individual participants to work independently, with synchronization mechanisms that allow them to combine their work to form a coherent whole. Finally, the authors show how the new transactional concepts developed in the project can be mapped into the transaction manager of an object-oriented database management system to provide a clean and efficient implementation.

xi

xii

This book summarizes the state of the art of key technologies in cooperative activities and transactions. As such, it would be very useful to students, researchers, and technology developers in these areas. Its particular value, however, lies in its ability to transcend the boundaries between the disciplines that until now had very little interaction. Researchers in the CSCW domain, will discover how much more predictable their systems will become, if they can provide guarantees that are expected from distributed systems and transaction monitors developed in different domains. Similarly, the developers of transaction monitors, may discover that the transactional mechanisms they created and of which they are Gustifiably) proud, are obviously inadequate, when applied in a new domain of work flows and cooperative activities. I hope that this book will be an important step in the convergence of CSCW, workflow and transaction technologies.

Marek Rusinkiewicz MCC

xiii

Acknowledgments

The authors would like to thank the following people for their contributions to the development of the TRANS COOP approach and the design and implementation of the demonstrator system: Peter Apers, Pieter Oude Egberink, Jari Juopperi, Hannu Kaijanranta, Tor Lillqvist, Ville Mikkonen, Erich Neuhold, Timo Salzsieder, Mohsen Sarabada, Bart Selders, Pekka Silvennoinen, David Spelt, Antoni Wolski, and Juha Ylii.-Jii.ii.ski.

We would like to thank Marek Rusinkiewicz (University of Houston / MCC) who was visiting scientist at GMD-IPSI, and Jian Tang, visiting scientist at VTT, for their stimulating and valuable input during their visits of the TRANS Coop project.

We also would like to thank the CEC project officers, Khalil Rouhana and Leonardo Flores Aiiover, and the project reviewers, Pekka Lahtinen, Laurent Vieille, Gerhard Weikum and Pierre Wolper, for their valuable comments on how to improve, tackle, and solve critical issues during the project.


FOR COOPERATIVE APPLICATIONS

1

1.1 INTRODUCTION

INTRODUCTION Wolfgang Klas

Rolf A. de By Jari Veijalainen

In most institutions today, product development is done by teams of designers. No matter which kind of product is developed, there is a strong need for the designers to closely cooperate. The spectrum of cooperation is quite broad. It ranges from non-structured, ad-hoc cooperation over less-structured and less-guided cooperation schemes to very well structured and predefined collaboration schemes up to asynchronous, message-based cooperation. The broad range of cooperation patterns is addressed by several communities, most prominently by the CSCW and workflow communities.

Today's electronic tools in this field still mostly aim at the support of a single designer only, leaving the organization of cooperation to some organizational level not directly supported by the tools. Even though there exist tools to support concurrent use by several members of a working group, concurrent operations are mostly controlled by rudimentary, elementary mechanisms, i.e., by implicit or explicit 'user locks'. For example, consider text editors for writing documents. There are excellent text editors available, but there is no appropriate support for multiple authors working on the same document concurrently. Workflow systems provide controlled support and organization of the flow of work within a collaborating group of people. Hence, these systems seem to be a suitable approach to support well-organized and pre-defined workflows. System support for cooperation schemes in the middle of the spectrum is lacking

1

R. A. By et al. (eds.), Transaction Management Support for Cooperative Applications

© Springer Science+Business Media New York 1998

2 TRANSACTION MANAGEMENT SUPPORT FOR COOPERATIVE APPLICATIONS

and constitutes an interesting issue as not many solutions and systems have been developed so far.

Requirements originating from the cooperative behavior present in cooperative application scenarios are not met by traditional database technology, though the need of using database systems is obvious as sharing data is one characteristic of cooperative working environments. As a consequence, special solutions have been developed which try to compensate the lack of cooperative support by database systems. Components on top of database systems are needed which allow for description of the cooperative tasks, try to coordinate activities performed in the tasks, and map them to the basic mechanisms like transactions provided by a database system. Experiences with such solutions show that the overall architecture becomes very complicated and the interaction with database systems becomes much more complex at the application level. From a general perspective of technological progress the incarnation of such solutions that are always dedicated to a single application is a step backwards, because abstract schemes for different kinds of cooperation are missing, and when new applications have to be developed, new systems capturing the cooperative aspects of the applications have to be developed, too.

In this book we report about the results of the TRANSCOOP project which addressed the development of abstractions and tools based on database system technology that support a range of various kinds of cooperation schemes: adhoc schemes, less-structured and less-guided cooperation schemes, as well as well-structured schemes like workflows. In the following, we give an overview of the roots of and motivation for the project, its main objectives, the baseline and rationale behind the effort, and an outline of the book chapters.

1.2 TRANSCOOP OBJECTIVES

Today's software tools like text editors, CAD tools or software development tools provide only very limited support for cooperative scenarios.

Taking text editors as a simple example, there are excellent tools available, but they do not appropriately support multiple authors to work on the same document concurrently. This problem splits a cooperative authoring process into two steps: (1) Authors negotiate and coordinate themselves without tool support; (2) Authors work on the next update or version of the document on their own. These steps are iterated until the authoring process is finished. Merging the steps can improve speed and quality of the authoring process significantly. Software tools supporting cooperative work in such a way are needed and start playing a more crucial role in innovative solutions for CSCW applications. Tools available today mainly support cooperative tasks on a very superficial level, e.g., by coordinating multiple users at the level of a window system, e.g., XWindows, without having any understanding of the data multiple cooperating users are working on simultaneously.

A major conceptual problem in this framework is to ensure consistency criteria for the data concurrently processed by multiple users. Conventional

INTRODUCTION 3

database technology already provides mechanisms to absolutely guarantee consistency constraints by controlling the concurrent access of different users to shared data. Unfortunately, existing transaction management concepts are not suitable for supporting and controlling cooperation between users, because they are designed to fully isolate users from each other. But, on the other hand, without providing system-controlled access to shared data, a tool for cooperative work will also be of little value because there is no way to automatically avoid inconsistencies, and ensuring consistency constraints will be up to the users.

Another serious problem is the design of cooperative systems itself, which is a very complex and error prone task, involving several formalisms and techniques that have up to now hardly been studied in combination. Formal techniques well-known from the field of designing non-distributed information systems as well as some promising approaches accomplished in the field of open, distributed information systems have been accepted by a large user community within each of these fields. But the design of cooperative systems includes the description and formal specification of cooperative activities. That is, formal techniques are needed to capture the notion of cooperation at the design level and to allow for the specification of cooperative tasks. In addition, such specifications have to be mapped to a cooperative execution and transaction management model in order to enable appropriate database management support at run time.

Cooperative transactions are thus intrinsically complex operations that are difficult to understand completely. A theory is needed for distinct notions of correctness, for simulation models, for the generation of tests, for compiler building and report generation, for correctness-preserving transformations that allow the designer to map specifications onto implementation platforms in a guided way. The whole process needs to be supported by a coherent set of tools.

The objectives of the TRANSCOOP project were as follows:

• to identify the requirements for a cooperative transaction model in selected types of cooperative applications and the characteristic differences in comparison with existing transaction models,

• to develop a specification language which allows to describe cooperative tasks, and which can be supported by a cooperative transaction management mechanism,

• to implement a tool set on the basis of the specification language using existing tools like LOTOS in order to allow for simulation and correctness proofs of cooperation schemes,

• to adapt and extend an existing transaction model towards the support of cooperative environments such that it meets the requirements given by selected application types,


• to allow for the deduction of formal properties of the chosen model in order to allow for the development of formal means to describe the model in order to prove specified properties such as correctness and completeness,

• to integrate the cooperative transaction model into an existing prototype of a database system, i.e., an object-oriented database system, and

• to implement a demonstrator which proves the applicability of the approach for a selected application scenario, i.e., to demonstrate the suitability of the specification language to describe and specify cooperative tasks and its run-time support by the cooperative transaction management mechanism.

1.3 APPLICATION REQUIREMENTS-THE DRIVING FORCE BEHIND THE SCENE

The research activities were directed by the requirements derived from the following application scenarios:

Cooperative Authoring This application scenario focuses on the authoring of documents by multiple authors. The requirements have been derived from the SEPIA project developed at GMD-IPSI during the last five years, partially in the context of the ESPRIT projects HYTEA and HIFI. The aim of SEPIA was to provide powerful, cognitive adequate support for authors of multimedia hypertext documents. SEPIA distinguishes between four problems of the authoring process explicitly: planning the document structure, identifying arguments, giving the document a rhetorical structure, and writing the contents of the document. SEPIA also supports writing of a single document by several users concurrently. Different modes of cooperation from individual mode to tightly coupled mode are available. A change of modes can be done interactively during the authoring process. Both the differentiation between different authoring activities and the support of concepts for different kinds of cooperation up to a tightly coupled WYSIWIS-mode made SEPIA an interesting application for cooperative transaction models.

Originally, the SEPIA system was developed on top of a commercial, relational database system storing the data shared by the authoring tools. In a later stage, the relational database system was replaced by the object-oriented database system VODAK developed at GMD-IPSI. Experience with the prototypical implementation of SEPIA has shown the urgent need to get more support from the underlying database system for handling and controlling cooperative authoring activities. The original SEPIA architecture required additional components on top of the database system which try to compensate the lack of cooperative transaction management support. The additional mechanisms highly interfered with the traditional notion of transactions and hence led to complicated and sometimes inefficient solutions.

INTRODUCTION 5

Design for Manufacturing The design of a product is influenced by several factors, e.g., functionality, quality, technical constraints, ease of transportation, and reliability. In fact, the design of a product influences, of course, the later phases of the product's life cycle, but the contrary also holds: Aspects relevant in later phases of the life cycle will influence the design, e.g., the way in which maintenance has to take place. The approach to take into account (during the design phase) aspects of later phases of a product's life cycle is called Concurrent Engineering.

Within TRANSCOOP we concentrated on a special form of Concurrent Engineering, named Design for Manufacturing (DfM), by considering only the design, process planning and manufacturing phases of a product. DfM integrates as much as possible design, process planning, and manufacturing. Hence, DfM corresponds to a cooperative activity of designers, process plan designers, and manufacturing experts. This implies that the support of information systems has to be integrated too. This integrated information system has to be used cooperatively by designers, process planners and manufacturers, and this imposes certain requirements on the system.

Inter-organizational Workflows The infrastructure for an electronic storage and exchange of formatted documents between organizations is maturing. For instance, the main government offices in Finland can communicate through a fast network which makes it possible to exchange material and information in an electronic form. Electronic mail can be used to convey informal information, but it does not cover the need for exchange of formal and legally binding documents, which must be processed by several distinct parties.

The current notions of transactions are inadequate in such a scenario, although traditional transaction mechanisms offered by database systems can be used to guarantee atomicity of operations needed. The special flavor of problems here stems from the fact that the work object itself is 'traveling around' in the network and, additionally, there might be several related work objects (document sets) following different paths.

The application scenarios described here cover different styles of cooperation from fully synchronous to fully asynchronous work. For example, the cooperative document authoring scenario requires support for both styles: several authors might edit the same document simultaneously or might be forced to edit it in a prescribed order.

We have analyzed all requirements resulting from the above cooperative environments and we have obtained a prototypes of the first one, i.e., the SEPIA cooperative document authoring environment, for integration with the results of this project to assess the feasibility of our solutions for supporting cooperative work.


1.4 SPECIFICATION LANGUAGE FOR COOPERATIVE TRANSACTIONS

Our specification language for cooperative transactions is based on the protocol specification language LOTOS and the database specification language TM. The objective is to show that a combination of these two formal languages provides an appropriate vehicle to define cooperative environments, mainly because this combination encompasses state-of-the-art data modeling through an object-oriented data model for monolithic database specification together with an orthogonal way of process modeling of many such (possibly heterogeneous) systems to describe their interoperability. Since such combined definitions are intrinsically complex and difficult to overview, tool support is strongly required to deduce characteristics of the overall system specified such that verification of the specification remains possible. FUrther tool support is needed for taking full advantage of the new transaction model that is to be developed.

As a result of this effort we expected a fully functional tool set that supports the design of cooperative environments, by specifying their monolithic behavior in situ, as well as the combined behavior in cooperating systems in a way that allows reasoning over the specification.

1.5 COOPERATIVE TRANSACTION MODEL

Conventional transaction models do not support cooperation between users. Their goal is to guarantee consistency constraints independent of application semantics, i.e., without the need for the transaction management to know about the required constraints. Violations due to interleaved executions of transactions are avoided by the transaction management. This completely frees application developers and users from specifying any consistency constraint explicitly to the database management system. The constraints are usually embedded into the program code. The price that has to be paid is complete isolation of user transactions from each other. A user is not allowed to see changes of data made by other users as long as the other users do not commit their transactions. That is, serializability and isolation are too strict, and the all-or-nothing property (complete rollback in case of failure) as well as blocking as implemented by pessimistic concurrency techniques do not meet the requirements of long interactive user controlled transactions.

Some of these limitations have already been overcome by new transaction models, going beyond the conventional meaning of transactions. Most of these models consider a hierarchy of subtransaction executions implementing a user transaction. User transactions are interactively composed instead of precompiled. Relaxed definitions of isolation between (sub)transactions provide for an increased degree of concurrency. As relaxed isolation will probably lead to violated consistency constraints, the degree of relaxing isolation is application dependent and has to be defined by the application developers. Most models lack a well defined mapping from the kinds of consistency constraints required by an application scenario to the parameters controlling the degree of isola-

INTRODUCTION 7

tion. Without such a mapping, an explicit definition of allowed interleaving of operations has to be given by the application developers which is impossible to manage in most cases. In addition, different consistency constraints have to be supported for different system levels. For example, at the data management level (transactional level) constraints have to be enforced different to the ones at a higher level of abstraction, e.g., the organizational level. Many low level operations require full isolation from each other, because they implement basic system services independent of applications that possibly cooperate.

As a main result of this project, we developed a transaction model for cooperative applications that can support arbitrary cooperation schemes according to application needs. The goal in comparison to other models wa3 to develop a powerful, but easy to understand way for defining application dependent execution constraints that are enforced by cooperative transactions. Our model was influenced by the open nested transaction model, the split/join transaction model, the check-in/check-out model, and the group transaction model.

The following key features of cooperative transactions are supported by our model:

• Exploiting the semantics of operations specified in a high level language in order to develop a new correctness criterion beyond traditional serializability.

• Enforcement of different application-dependent execution constraints at different system layers, e~g., organizational constraints concerning the organization of collaboration and the constraints on the transactional level.

• Support for long-running interactive user-controlled and user-composed transactions.

• Relaxed atomicity of transactions, Le., a transaction should be able to commit even if parts of it fail.

• Version support, in order to explore different solutions of the same problem by different users without interfering each other.

1.6 ROOTS AND BACKGROUND OF THE PROJECT

The project was a joint effort of the database research group at GMD - German National Research Center for Information Technology, Integrated Publication and Information Systems Institute (IPSI), Darmstadt, Germany, the database research group at the University of Twente, The Netherlands, and VTT Information Technology, Finland. It was partially funded by the European Commission under the Basic Research Program Grant No. ESPRIT P8012. The project started in April 1994 and was finished in June 1997.

The project was coordinated by GMD-IPSI which was also responsible for the development of the transaction model-related issues and the implementation of the run-time environment. The University of Twente was responsible for


the development of the specification language and tool set. VTT developed a graphical editor and together with the other partners particular modules of the final demonstrator system, which is based on the SEPIA application scenario of GMD-IPSL

The project was triggered by the common understanding and experience of the project partners with respect to the lack of suitable support for both the specification of arbitrary cooperation schemes and the transaction management support for cooperative applications. Experiences from previous projects had shown that there is an urgent need for a better understanding and development of abstractions to deal with cooperation schemes which avoid the expensive realization of cooperative system primitives hard-wired with cooperative applications.

1.7 OUTLINE OF THE BOOK

Chapter 2 outlines in more detail the basic ideas and issues of the TRANSCOOP project. It explains the fundamental decisions and the methodological approach taken, the basic concepts and notions including the corresponding terminology. It serves as the starting point for an overall understanding of the general TRANSCOOP approach.

Chapter 3 discusses related work in the field of transaction models for cooperative applications.

Chapter 4 presents the application areas we looked at in order to derive concrete requirements for the design and development of the specification language, the transaction model, and their implementation by means of a specification language tool set and run-time environment. These requirements have significantly driven the project in order to achieve basic research results which have the potential for further development and application in practice.

Chapter 5 outlines the architecture and system structure developed in the project. It includes a reference architecture which allows for a general view on the architectural issues. This reference architecture was the starting point for the development of the system architecture used for the implementation of the TRANSCOOP demonstrator which is described in detail in Chapter 8.

Chapter 6 discusses in detail the TRANSCOOP specification environment. It describes how a designer can define cooperative scenarios using the CoCoA language. It deals with the organization of the collaboration, as well as with the data sharing issues involved, including a range of particular restrictions that scenario designers may want to impose on the users participating in the collaboration.

Chapter 7 presents the TRANSCOOP cooperative transaction model COACT. It discusses how interactive, cooperative activities can be supported. The emphasis is not on preventing access to resources (like in a serial world), but rather on the interoperation, i.e., the semantically correct exchange of information, among concurrent activities of cooperating, Obviously, in such environments failure atomicity may be too strict, and isolation among concurrent users con-

INTRODUCTION 9

tradicts the need of cooperation. Hence, in COACT we replaced these criteria by new ones which are more suitable for cooperative applications. The chapter uses a running example for illustration which is also used to describe the TRANSCOOP demonstrator system.

Chapter 8 gives a description of selected parts of the TRANSCOOP demonstrator system, the demonstrator specification environment and the demonstrator run-time environment. The demonstrator system is one of the main results of the project, demonstrating the usefulness and applicability of the scientific results of the project. The system is used to illustrate how cooperative scenarios are specified, validated, compiled for execution, and finally executed within TRANSCOOP. The particular domain of demonstration is Cooperative Hypermedia Document Authoring (CDA). This domain is easy to understand for a broad audience and allows demonstrations of various cooperation schemes due to its flexible working style.

Chapter 9 summarizes the project results and outlines our ongoing and future work.

2 THE TRANSCOOP PARADIGM

2.1 INTRODUCTION

Jari Veijalainen

Rolf A. de By Karl Aberer

This chapter serves as a gateway to the subsequent chapters of the book, as it poses the basic ideas and questions concerning transactional support for cooperative work and explains the fundamental decisions taken to tackle the questions. Therefore, this chapter is warmly recommended to any reader of the book.

We first describe the motivation for the TRANsCoop project, the initial problems we had in mind, and the methodical approach taken to solve the problems. We also explain why we chose certain application areas and products to be more closely analyzed. Further, we explain why we thought that objectoriented database technology combined with an open nested transaction model (as embodied in VODAK), and the LOTOS/TM language, equipped with an appropriate tool set, could be useful in solving the concurrency, reliability and atomicity problems inherent in systems supporting cooperative work.

In this chapter we also introduce the basic concepts and notions developed in the project and the corresponding terminology. Especially, we introduce our notion of cooperative work and its consequences for systems supporting it. The approach is historical in the sense that we expose to the reader our deepening understanding of the problems and issues and the changes caused by this in the meaning and scope of our concepts.

Finally, we position the work done in the TRANSCOOP project within the larger field called Computer-Supported Cooperative Work (CSCW). The posi-

11




tioning is mainly based on our notion of cooperative work and the application areas chosen to represent the concept. The positioning of our work with respect to transactional support for cooperative work is done in Chapter 3.

2.2 MOTIVATION

Resource management is a central issue in a number of Computer Science fields such as operating systems, databases and computer networks. It is needed because most resources-regardless whether we consider hardware, software or data resources-are costly, unique, or both, and thus need to be shared by numerous users or software modules. By their nature, many resources-for example printers, CPU's, and many secondary storage media-are incapable of allowing truly concurrent usage, and thus they need to be managed by software that offers seemingly concurrent usage to the user community. Depending on the underlying computational model, the granularity of concurrency required, and the type of resource involved, software techniques such as semaphores, buffering, prioritization and locking have been found to offer efficient, consistency-preserving solutions.

In data management, and especially in the management of administrative data, transaction protocols have been defined around the notions of atomicity, consistency, isolation and durability (Le., the ACID properties). In this type of application, the concept of a-from user's point of view-indivisible operation with a lasting all-or-nothing semantics that guarantees data consistency afterwards-in other words the notion of transaction-is a proven and widely accepted building block for larger applications. The theory of serializability and reliability/recoverability [Papadimitriou, 1986, Bernstein et al., 1987] permits the database management system software to be as permissive as possible in implementing transaction isolation and atomicity, thereby removing a potential performance bottleneck.

In recent years, the data management field has witnessed a number of developments that caused an upsurge in research of data sharing techniques. First, an emerging need for extended database support in not-so-standard applications led to the study of complex object models. The fields of computer-aided design and manufacturing, industrial engineering, geographic information systems, scientific databases and quite a few others simply require more complex structures than the flat records of administrative databases for their operation. These structures correspond most naturally with the (industrial) artifacts that are being designed and developed.

But not only are the structures used in these fields required to allow more complexity, the data management software must also accommodate the concurrent use and updating of these structures at a much more intensive scale. The most important reason for this is that a good design and a short-time-tomarket of the subsequent product can only be obtained nowadays by highly interactive designer teams. Their members have to cooperate closely on the

THE TRANSCOOP PARADIGM 13

product, and as a consequence, they heavily engage in product data sharing during their work.

As we have observed, however, standard transaction management techniques are not suited for cooperation between a group of users, but were developed to support isolation between users. What is needed in this context of cooperation is a notion of transaction that relaxes the requirements of atomicity and isolation, and accommodates a more opportunistic style of data handling.

Finally, part of our work is also motivated from the observation that users who engage in cooperation become agents in a larger scheme process, in which not only data manipulation but also inter-agent communication (in various disguises) and process control play important roles. The TRANSCOOP consortium also wanted to address these process dimensions, as well as techniques to describe and study the dimensions.

2.3 METHODOLOGY APPLIED

The TRANSCOOP project was planned to take the 'long path' from the start to the goal. That is, we wanted to analyze real needs of real application areas and deduce from them 'typical' system requirements and especially transactional requirements, the central issue in the project. Based on these, a transaction model matching the requirements was to be developed. And finally, the model developed was to be implemented as part of a demonstrator in order to test its feasi bili ty.

There are certain intricacies in the above approach. First, there must be an insight that existing transaction models do not match the requirements, otherwise it does not make sense to begin to develop a new transaction model. But how did we know this before we had made the analysis? Actually, we did not know exactly, only vaguely. The intuition was that the open nested transaction model (or other similar models proposed to support cooperativeness) was not sufficient to support the application needs we were to include into the analysis, since it still used isolation as correctness criterion. The hope was, however, that it could be enhanced to match the new requirements.

Second, when one begins to analyze real applications, the transactional requirements are not directly observable-unless the technology is already used and problems solved-rather, they must be 'discovered'. This can be exemplified by the PORTNET example in Chapter 4 (see Section 4.2.4). The PORTNET system is an ED! system and at the global level does not have any transactional mechanisms. One could thus draw the conclusion from the analysis of the application that because it functions without global transactional support, such a support is not necessary. The closer analysis reveals, however, that there are certain nasty problems, which could be understood as a lacking global transactional support. By 'superimposing' a global transactional mechanism into the PORTNET environment one can understand the problems and also see how the mechanism should function in order to help to avoid the problems. By doing so, it was possible to come to a new theoretical and practical prob-


lem: how to handle many instances of the same activity (or step) occurring in a workflow, when the number of instances is not known in advance? We could also show that compensation is a reasonable transactional ingredient in the environment (see [Tang and Veijalainen, 1995c] for details).

Third, because the applications or systems analyzed require new transaction model(s} and corresponding mechanisms to be invented, the question arises: which problems should be considered as "transactional" and thus tackled with "transactional means" which not? Here the answer is that we had a certain pre-understanding of problems of transactional nature that thus can be tackled by transactional means. Based on this pre-understanding we separated the requirements that were transactional from other 'system' requirements during the requirement analysis phase (see Chapter 4).

When writing the proposal in 1993, we had a rough understanding at the level of Elmagarmid's book [Elmagarmid, 1992] on advanced transaction models. During the project, we made a rather extensive survey study of the relevant research literature, as documented in [Tesch and Verkoulen, 1995, Klingemann et al., 1995]. Thus, methodically we used a survey as one approach.

How did we choose the application areas (cooperative authoring, design for manufacturing, workflow management) and the concrete applications and systems? They were selected partly because of organizational reasons (system accessible, somebody had contacts to the company, etc.), partly because the problems seemed to be interesting in the light of our pre-understanding (Fokker case, Valmet case, PORTNET case).

We also wanted to study real commercial systems and relate the requirements with their properties in order to see how well the market place had already responded to the needs of applications and to avoid unnecessary efforts. Methodically, the above two studies were made as case studies, i.e., we selected some applications and real systems which seemed to be representative for the field. These were partially tried in practice by obtaining licenses and programming small examples; partially the information was collected from manuals and interviews with relevant people. Clearly, case studies always have the problem that one does not know how representative the chosen cases are in general terms. This can be judged only in the future.

The second step was to develop an architectural model and a coherent 'transaction model' matching the requirements. The architecture work resulted in a reference architecture [de By et al., 1995b] and an instantiation of it, the latest version of which is included in Chapter 5. Concerning the transaction model, the basic idea was that once we had been able to state what the 'transactional properties' deducible from the requirements were, we were able to deduce the 'transaction model'. Once the model was designed, it was possible to say how the specification of a single transaction should look and what facilities the specification level should provide. This made it possible to design the specification language with which to describe the transactions. The results of the work are reported in Chapter 6.


The final step of the project was to design and implement a demonstrator system embodying essential features of the specification environment and runtime environment supporting the transaction model developed. By doing this, existing tools (see the pre-requisites in Section 2.4) have been modified and enhanced. The demonstrator is described in Chapter 8.

The overall approach of TRANSCOOP can be described by Figure 2.1 below. Analysis is broad, at the model level we narrow down, addressing less issues and requirements than in the analysis phase. Further, the specification level does not support all properties envisaged for the transaction model. Finally, the demonstrator covers only a few key aspects originally analyzed.

The main goal while building the demonstrator was to show that it is possible to design and implement a run-time system that is able to run the code generated from the specifications produced in the specification environment.

Spedftcatlon Environment

Application Analysis

Figure 2.1 Overall scope of the TransCoop project

2.4 TECHNICAL PREREQUISITES

The TRANSCOOP project had certain technical prerequisites. The run-time system was to be based on the exploratory object-oriented database management system VODAK with its open nested transaction model (see Section 2.4.1), suitably enhanced to support new requirements encountered in the analysis phase of TRANSCOOP. The specification and formal verification of the cooperative transactions was to be based on LOTOS and TM (see Sections 2.4.3 and 2.4.2).

2.4.1 VODAK and the Open nested Transaction Model

Support for cooperative, multi-user publishing processes has been a major research and development topic at GMD-IPSI. Database systems are an important component in a publication environment where users want to use the publishing resources concurrently and want to cooperate when creating new


publishing products. Conventional database management systems cannot cover all demands that are imposed by the needs of publishing applications. Publication environments use heterogeneous information resources, which have to be explored and from which relevant information has to be filtered out. The document types required for publication include multimedia data types, like image, audio and video, which have to be supported by the database system in an integrated manner. Publication processes are structured differently from classical transaction programs, with activities that consist of many subactivities, some of them long-lasting. Many activities require support of cooperation.

With these requirements in mind starting in 1989 a new Database Management System VODAK has been developed to better support the nonstandard database requirements arising from publication environments [Neuhold and Turau, 1992]. (VODAK is the German acronym for "Verteilte Objekt-orientierte Datenbanken" which means "Distributed Object-oriented Databases.") From the data modeling viewpoint, VODAK includes not only standard features of object-oriented database management systems (such as object identity, encapsulation, complex data types, inheritance and polymorphism), but also advanced modeling concepts that have been designed to provide better support for the integration of heterogeneous information resources [Klas et al., 1994a, Klas et al., 1994b]. These are strict separation of types and classes [Geller et al., 1991] to clearly distinguish extensional from intensional aspects in data modeling and meta-modeling [Klas and Schrefl, 1995] capabilities. Meta-modeling allows to extend the data model with new data modeling constructs, like semantic relationships, which are usually hard-coded into the database systems.

VODAK has a standard client-server architecture [GMD-IPSI, 1995], where the server can rely on different storage managers. In the first version this was the nested relational database system DAMOKLES [Dittrich et al., 1987]. The version used in the TRANS COOP project was based on the object-oriented C++-based database system ObjectStore [Lamb and Landis, 1991]. Some of the design decisions taken in the VODAK architecture and its implementation turned out to be quite favorable for future extensions and adaptations, like those that have been implemented in the context of TRANSCOOP. This holds for the logical object identification, the object buffering, the dynamic method handling and the extensible data dictionary.

The VODAK database system has been extended to support multimedia data types [Rakowet al., 1996], including in particular continuous media types, like audio or video. With regard to the data model new base data types have been introduced. Exploiting these and the meta-modeling concept basic modeling constructs for complex multimedia document types, like those that have been used in TRANSCOOP, have been implemented [Wiisch and Aberer, 1995, B6hm and Aberer, 1994]. The system architecture needed to be extended in particular with components supporting the storage, the transport, and the presentation of continuous multimedia data [Boll et al., 1996] taking into account their (soft) real-time requirements.


A particular application exploiting these extensions was the implementation of the hypermedia document model [Wasch and Aberer, 1995], on which the cooperative authoring tool SEPIA [Streitz et aI., 1992] was based, which was developed at GMD-IPSL To that end first a basic set of hypermedia document modeling primitives, including atomic content objects, composite objects, hypertext links and activity spaces, were developed, using the meta-modeling approach of VODAK. This approach allowed to move a substantial part of the hypermedia application semantics into the database management system, thus simplifying development of hypermedia applications, allowing to perform complex operations more efficiently within the DBMS, and enforcing consistency constraints in a multi-user environment for the application-specific semantics within the DBMS. Using these hypermedia modeling primitives the SEPIA document model was instantiated. This implementation formed the basis for the TRANSCOOP demonstrator application. Having the application semantics available within the database application schema was an important prerequisite for TRANsCoop for enabling cooperation at the level of complex, applicationspecific operations.

Conceptually, VODAK includes an important prerequisite for the transactional aspects of the TRANS COOP project, the open nested transaction model [Weikum and Schek, 1992]. It has been developed with the requirement of cooperation in multi-user publishing environments in mind. The goal of the open nested transaction model is to minimize waiting times and waits in long-lasting activities that concurrently access complex documents in a database. However, the open nested transaction model is adhering to the standard correctness criterion of ACID transactions, namely to serializability, although a generalized one.

The main problem with complex operations in context of transaction processing is that waits are little appreciated by users if they are not caused by consistency violations from the user's point of view but rather they result from concurrent access to data at a system level, e.g., at the page level. Therefore, in open nested transactions, conflicts are defined with respect to the semantics of operations, such that waits will be caused by conflicts based on the application semantics. To indicate conflict-freeness of operations, semantic commutativity relations (large, two-dimensional tables that specify when pairs of operations are conflict-free) must be specified for transactions that are structured in different abstraction levels. Thus, open nested transactions combine the following two principles:

1. Commutativity of operations is defined semantically: As opposed to conventional concurrency control based on the read/write model (see Chapter 3, Section 3.2.2), where only the read operations among operations on an object commute. A more elaborate semantic definition of commutativity also allows some update operations to commute. Commutativity definitions are specified for the methods occurring in a schema conforming to the object-oriented data model of e.g., VODAK.


2. Levels of abstraction are considered: Operations on a higher level are implemented by sequences of lower-level operations. In an object-oriented environment, the levels are given by the calling hierarchy of the methods and are thus not limited by depth. Changes performed by a subtransaction to the persistent data are made visible to other subtransaction at the same level provided they commute with the committed subtransaction. Thus a potentially higher degree of parallelism is achieved than in system implementing the read/write model. For that reason, the transactions are called open, as subtransactions can make their results visible before the overall transaction is completed.

For the open nested transaction model the correctness of a history has been defined and a locking protocol has been given. The compensation of open nested transactions in case of transaction abort or crash is performed by compensating operations, since a conventional state-based undo is no longer feasible in the open nested transaction model. The concept of compensating operations turned out to be also relevant for the cooperative transaction model of TRANSCOOP. The open nested transaction model has been implemented as part of VODAK requiring extensions of various database system components, like the lock manager, the transaction manager, the schema compiler and the data dictionary, as described in Chapter 8.

2.4.2 TM for Specifying Monolithic Information Systems

In object-oriented database systems, programming is typically merged with data-structuring, enabling the designer of a database to have all the advantages of a clean conceptual design, as well as the possibility of enforcing better software engineering. In order to integrate database systems and programming languages, it was necessary to unify the database system (or information system) concept of data model with the programming-language concept of type system.

TM is a language that aims at providing such a unifying framework; it is a language for describing conceptual schemas of object-oriented databases [Balsters et aI., 1993, Bal et al., 1996]. Its strength stems from its richness as a specification language and its formal, type-theoretic background. It distinguishes itself from many other similar languages, including VODAK modeling language VML (see above), in having a completely defined formal semantics. The formal model has been based on Cardelli-Wegner type theory [Cardelli and Wegner, 1985].

TM language incorporates state-of-the-art features of object-oriented data models, such as complex objects and multiple inheritance, but it also extends known models to general set constructions, in the context of full static typecheckability. TM is equipped with its own design methodology and various tools have been developed for the TM language, amongst others a type-checker and a prototype generator.


By extending existing object-oriented data models with a logical formalism and general set constructs, TM offers a wide range of possibilities for describing database schemas in an object-oriented framework. In contrast to the ADT theory of LOTOS, which is based on the construction of initial algebraic models, the TM model has been given a purely declarative, set-theoretic semantics. We believe that the latter approach may lead to more intuitively appealing data models in the specification of information systems.

Another reason for using a language in which complex objects can be directly defined stems from the observation that databases typically consist of large collections of data showing many interrelationships. In databases, these interrelationships deal with various kinds of referential integrity and the organization of data in so-called generalization/specialization-hierarchies.

In object-oriented type theory, generalization/specialization is described by means of a subtyping relation. In ADT theory, there also exists a need for expressing interrelationships between data by employing subtyping. Although there exist approaches to incorporate a notion of subtyping in ADT theorymost notable is the approach taken in the OBJ model [FUtatsugi et al., 1985)the resulting systems lack readability due to heavy use of mathematical formalism.

2.4.3 LOTOS for Specifying Distributed Systems

LOTOS is an internationally standardized formal description technique [Bolognesi and Brinksma, 1987) for the specification of distributed, concurrent systems. In particular, it has been developed for the formal definition of OSI service and protocol specifications.

LOTOS is based on a process algebraic model that allows for an explicit treatment of parallelism and nondeterminism. The model induces a powerful analytic theory that can be applied to the analysis and transformation of specifications. This has enabled the development of LOTOS-based design methods and a sophisticated LOTOS tool environment, which give LOTOS great practical strength in spite of its complete formal semantics.

The pure process algebraic language (so-called Basic LOTOS) has been orthogonally extended with an abstract data type (ADT) formalism (viz. ACT ONE) for the definition of data structures that are used for both the definition of communication data and parameterization of behavior expressions (cf. [Bolognesi and Brinksma, 1987, ISO, 1987)). In itself, therefore, LOTOS provides a complete formal system for the description of distributed information systems.

In practice, however, information systems are rarely specified using ADT's, whereas relational, entity-relationship or (more recently) object-oriented languages are most frequently used. Just the redefinition of such data models in terms of ADT definitions-which would be required when using standard LOTOS-would already be an enormous task.


Moreover, the use of an ADT formalism for the specification of data structures in LOTOS has been a source of criticism in the context of more pragmatic applications of the language where the use of non-constructive specification features at a high abstraction level is less relevant. Also from this perspective, there exists considerable interest in the combination of LOTOS with other formalisms for the representation of data types. Experience with such alternative combinations could be used as input material for a probable revision of the International Standard.

The idea in the TRANSCOOP planning phase was to substitute the ADT part of LOTOS with the data type system of TM, and at the same time modify the combined language to allow its use to specify cooperative transactions and verify their properties.

2.5 TERMINOLOGY AND CENTRAL NOTIONS

Paradigmatic Terms

While entering the field of Computer-Supported Cooperative Work (CSCW), it makes sense to agree on some terminology. In this section, we list a number of the most common terms found in the chapters of this book, centered around the topics of paradigm, architecture, user community and transaction model. Where these are due, further notions will be introduced in subsequent chapters.

CSCW can be defined as the area that addresses the use of computer systems to enable human users to intensively collaborate on a well-defined, common goal. Tasks comprising the collaboration should clearly allow to be accommodated by computer systems, and the user community should equally be willing to act according to the system's set-up. The notion of agent (also called actor) is normally used for either human users, or for system components with at least some degree of action autonomy. This is the human-system dimension.

A cooperative activity or scenario, as we will also call it, aims to perform a common goal or task. Scenario is a specification-level concept. It may identify subtasks, assigned to only a subset of the agents involved in the scenario, and this gives rise to further primitives to organize the subtasks. The reason is that scenarios defined in terms of subtasks require task organization, or in other words, seen as a process description, the scenario should identify which events may happen, and state what their consequences for the scenario will be. This is the process dimension.

There is a third dimension at this level, which we may call the data dimension. It tells us which data sources playa role in the scenario, and how these are organized. Of utmost importance in this respect is the generic data handling facility provided; in other words, the transaction model in use. The TRANSCOOP project has focused from the start on applications for which the assumption of a single object base schema, and a single, generic transaction model is not overly restrictive. We have, however, also paid much attention at allowing highly complex data schemas and defining generic transaction functionality.


Architectural Terms

Applications in the field of CSCW require intelligent support systems that accommodate monitoring the progress of the cooperation process. In our project, emphasis was put on two issues: the support of correct and consistent data manipulation functions, and the precise description of cooperative scenarios.

Most naturally, our system architecture identifies a run-time system, in which the transaction model is embedded, and a specification environment, in which the scenarios should first be defined. The run-time system and the specification environment together form a transactional framework. The run-time system deals with end-users, i.e., the workers active on the scene of cooperation, and it accommodates the use of volatile and permanent data, possibly adding data replication techniques to it. We return to transaction model notions below.

The specification environment is used by scenario designers: workers behind the screen who prepare the scenario for execution. Their major tool is the specification language, which is based on object base types and a process language. This language allows to define certain properties of the scenario, like its organizational structure, the end-user roles involved, and a number of the transactional properties surrounding the data that is the subject of cooperation. The language allows to define three classes of user-initiated operations: data manipulation operations, data exchange operations, and communications, which allow certain forms of end-user interaction.

User Community Terms

We have already made the important distinction between the workers on the scene, the collaborators, who we view as the end-users of our system, and the workers behind the scene, the most important of which are the scenario designers. They will have to ensure the scenario offers those capabilities that are required for a successful cooperation.

In a cooperative scenario, which will be undertaken by a group of users, quite often smaller tasks will be identified within. Since this is all about cooperation, for those smaller tasks again a user group will be assigned to have the responsibility of finalizing it. The collaborators in a user group will be given certain privileges to enable them to carry out their task.

Finally, we mention that when we speak of users, it is not necessarily the case that we mean to identify actual people as collaborators. The specification language, as well as the run-time environment, allows to identify user roles, which can be understood as variable slots that at some later point in time can be filled in with real people. A user role thus functions as an intermediary language structure between an abstract user notion in the scenario, and the person who will carry out the work.


Transaction Model Terms

We have already used several transaction modeling terms above without going into definitions. We will give here an intuitive understanding of at least the core terminology that will help understanding other parts of the book, without the need to consult Chapter 3, where a more elaborate treatment is given. A transaction model is a theory of handling shared, concurrently accessible data with a system that implements this access. A transaction model is a special kind of a model used to describe computations occurring primarily within a database management system. The ultimate goal of the model is to precisely express under which circumstances handling shared, concurrently accessible, persistent data is correct, drawing diverse failures also into consideration. The key problems follow from this definition: we have data sources that we want possibly many users to share, and we want to allow them concurrent access to this data, under additional assumption of system and other failures.

Potential solutions very much depend, for obvious reasons, on the type of user application, the intensity of concurrency and types of failures. In administrative data applications, the paradigm is a single-user application style, and a transaction is usually viewed as a single execution of an application program that performs its task, yet leaves the data in a consistent state for further use. This consistency (C) is an important property of the transaction programs, because implementation of the transaction management system relies on it.

Several properties, besides consistency, have been defined to make transactions what they are, i.e., they are the properties that distinguish these computations from other kind of computations. Atomicity (A) is the property that a transaction carries out all of its tasks, or, when failing to reach a consistent post-state, it has carried out none of its tasks. Within the DBMS, logging and recovery protocols are used to ensure this property. Isolation (I) means that the transaction does not make its internal actions, and hence the effects they have on the data, available to other transactions before it has done all of them, i.e., before it has committed. To achieve isolation in the presence of concurrent access to the data sources, several notions of serializability have been used and access protocols, often based on locking schemes at various levels of data granularity, have been implemented. Finally, durability (D) means that once a transaction has eventually committed, the effects on the data are permanent, and can only be undone by another transaction.

Together the above properties are often called ACID. We discuss them in more depth in Chapter 3.

It should be clear to the readership that above-mentioned properties seem suitable in administrative worlds, but much less so in contexts where the purpose is to accommodate the cooperation between end-users. In such contexts, atomicity is still considered valuable, but it should be a relaxed type of atomicity, that allows in-between versions of the data sources. Consistency, obviously, is still a most valid concept, but isolation, on the other hand, isn't really. At least, when we define isolation as shielding off the effects of the actions of a


single user from those of others, it is not what is wanted. Isolation could, however, also be defined as shielding off the actions of a group of users from those of other groups, and then it starts to make more sense again.

2.6 POSITIONING TRANSCOOP WITHIN THE CSCW FIELD

Computer-Supported Cooperative Work can be characterized as a relatively new and dynamic field of research dealing with the development and use of groupware technologies in organizations [Ngwenyama and Lyytinen, 1997]. It is therefore rather natural that the discussion on the problem space of groupwork and the definition of the field itself continues and that there are no commonly accepted views on the borders and issues in the field. We therefore use several categorizations suggested in the literature to position the work in the TRANSCOOP project.

2.6.1 Characteristics of TransCoop

We use three characteristics of TRANSCOOP as the basis of positioning: our notion of cooperative work, the application areas analyzed and the demonstrator produced.

As discussed above, our notion of cooperative work is based on the idea that people (agents/actors) use a cooperative computer system to work together in order to achieve a common goal. The work objects (having representation as data) are supported by the computer system and there are automated tools to manipulate them. The cooperation is facilitated by shared work objects, i.e. shared data. The existence of symbolic interactions (discussions, phone-calls, face-to-face meetings, etc.) between the agents are known to exist but are not particularly analyzed and at work object level they are not supported as a special category. We also believe that the cooperative work process structure can be pre-analyzed and its structure made known to the cooperative computer system in form of scenarios.

The application areas analyzed were cooperative authoring, design for manufacturing, and workflow applications. The TRANS Coop-built demonstrator concentrates on cooperative authoring.

2.6.2 Groupware Classification

In [Ellis et al., 1991], there are three taxonomies for groupware, of which timespace taxonomy (Same Time/Different Times: Same Place/Different Places) and application-level taxonomy (message systems, multiuser editors, group decision support systems, computer conferencing, intelligent agents, coordinator systems) are most usable here.

Our notion of cooperative work does not exclude any of the four combinations in the time-space taxonomy.

Of the application areas, cooperative authoring belongs typically to the class Different Times / Different Places, but the cooperative authoring can be per-


formed also in any other mode. Workflow management belongs typically to the class Different Times / Different Places. Design for manufacturing is a complicated field with diverse parallel and sequential design phases (see Chapter 4, Section 4.3) and different phases might have to be performed in different modes with respect to the Time/Place classes. The TRANSCOOP demonstrator belongs to the Different Places / Same Time class mentioned above.

Compared to the application level taxonomy, our notion of cooperative work excludes those applications that do not have any people involved.

Of the three application areas studied, cooperative authoring belongs most closely to the area of multiuser authoring tool as the target was a multiuser authoring tool SEPIA [Streitz et al., 1992]. Workflow management systems are coordination systems, whereas the design for manufacturing requires support of several application categories (e.g., message systems, coordination systems, conferencing) .

The demonstrator is an asynchronous multiuser editor in terms of the classification.

2.6.3 Social Action Framework

This categorization is presented in [Ngwenyama and Lyytinen, 1997]. The authors define groupwork to be "a web of coordinated social actions, performed by the participants to achieve a joint outcome. The social actions of groupwork are situated within and normatively regulated by the organizational context."

The actions are classified into four categories: instrumental, communicative, discursive, and strategic actions. Correspondingly, the groupware can be classified into four categories based on the support for these actions.

Instrumental groupware supports creation, manipulation and transformation of objects-of-work and provide associated tools (cf. group editors, co-authoring systems). Communicative groupware supports group interactions at the symbolic level, so that group members can understand each other (cf. e-mail systems, bulletin boards). Discursive groupware supports problem solving, argumentation and critical debate so that the organization can find or re-establish common goals (cf. Group Decision Support Systems). Strategic groupware supports negotiating and bargaining processes (cf. negotiation support systems), the main aim of which is to influence people's behavior by other people.

Comparing the work and notions in TRANSCOOP with the above framework, our notion of cooperative work is mainly related to the instrumental actions in the above sense.

The software supporting applications in the areas analyzed belongs mainly to the instrumental groupware. In the first published version of the CoAct model [Rusinkiewicz et al., 1995], notifications were also addressed. This feature can be understood as a support for communicative actions in the sense above. Workflow management systems belong typically to instrumental groupware. There might be, however, support also for communicative actions (e.g.,


sending e-mail to other people). Design for manufacturing might need support of instrumental, communicative, and discursive groupware (negotiations).

The demonstrator built in TRANSCOOP belongs to instrumental groupware, as there is no support for other types of actions.

3 TRANSACTION MODELS IN COOPERATIVE WORK-AN OVERVIEW

3.1 INTRODUCTION

Jari Veijalainen

Jurgen Wasch

Juha Puustjarvi

Henry Tirri

Olli Pihlajamaa

In this chapter we review the earlier research and development work for providing transactional support for cooperative work. We start by discussing the fundamental concepts and database transaction modeling ideas developed during 1970's. These ideas can be crystallized into four properties: atomicity, consistency, isolation, and durability (ACID) which separate transactions from other computations.

The above properties are rather general, and in order to investigate more exactly their nature and to design concurrency control and recovery algorithms guaranteeing these properties, a more elaborate modeling of computations must be developed. The archetype of such models is the so-called read/write model (R/W model), which models transactional computations as read/write operation sequences accessing persistent data, with implicit or explicit commit/abort operations.

We discuss this model in detail, because many of the central concepts like serializability and recoverability can only be defined using a formal model, and because the concepts defined and issues raised by the model are fundamental

27




to transaction modeling in general. We then discuss the further development of transaction modeling ideas, driven by new applications areas, well beyond business applications.

In many application fields ACID properties, as formulated with the help of the R/W model, are too stringent to be imposed on the transactions. A large body of the transaction modeling research and development considers thus how some of the ACID properties, especially atomicity and/or serializability could be generalized in such a way that the requirements of the new applications are met. This often requires modification of the computation model, establishment of new or modified "transactional" properties the computations exhibit, and development of new architectures and algorithms which guarantee the new "transactional" properties. A typical example of a more complex computational model is a computation tree, where the leaves model read and write operations and nodes higher in the tree more abstract operations.

We close the general section by discussing a metamodeling approach, as embodied by ACTA [Chrysanthis and Ramamritham, 1994]. After having set up a framework, we turn our attention to the CSCW field and its requirements in Section 3.5.3 We also review many transaction models proposed for the CSCW field. Finally, we conclude that due to the CSCW field requirements there is a need for broader concepts. We call these transactional frameworks and they are discussed in the concluding Section 3.6.

This chapter is aimed at a specialist, it does not discuss the basic issues, such as existing concurrency anomalies or what a transaction crash means. Therefore we will heavily reference to the existing literature and urge the reader unfamiliar with the basic concepts to consult, e.g., [Bernstein et aI., 1987, Papadimitriou, 1986]. Less formal literature is [Bernstein and Newcomer, 1997, Ramamritham and Chrysanthis, 1997] and a very comprehensive book on transaction processing is [Gray and Reuter, 1993].

3.2 A BRIEF HISTORY OF THE TERM TRANSACTION MODEL

The term database transaction has been around over twenty years. Two original papers presenting the basic issues were [Bjork, 1973, Davies, 1973], which were followed by a period with overwhelming amount of papers on the topic. One of the most influential papers was [Eswaran et al., 1976] which introduced the read/write model, albeit in a tight combination with locking. The work reported in the paper was done while developing a relational database system, System R [Astrahan et al., 1976] at IBM.

This is not a coincidence, because the database manipulation language SEQUEL designed for System R did not provide facilities for explicit control of shared data by a programmer, hence the system had to take care of it-thus relieving the user from concurrency control problems. Such an approach requires appropriate principles with corresponding algorithms to be used within the database system in order to guarantee the correct functioning of the database system in any situation.

TRANSACTION MODELS IN COOPERATIVE WORK-AN OVERVIEW 29

Transaction programs

Database Management System

Figure 3.1 Traditional transaction modeling environment

What are the problems and what could be those principles and algorithms? There are two separate issues to be addressed, the concurrent usage of the persistent data, and diverse crashes (program or system crashes, etc.) that might happen during program execution. Errors caused by the concurrent usage of the database are called concurrency anomalies (e.g., lost updates and unrepeatable reads; see [Bernstein et al., 1987, Gray and Reuter, 1993] for details). Program or system crashes, i.e., failure anomalies, might cause committed updates to be lost, or uncommitted updates to be included, resulting in an inconsistent database state.

3.2.1 The ACID Properties

Transaction Management Architecture. A database transaction model addresses the above problems. While developing transaction model, the first logical modeling step is to postulate an abstract architecture which separates between three separate entities: transaction programs (applications), database management system (DBMS) and the persistent data, collectively also called database, as described in Figure 3.1. The separation of programs and the system makes evident that there must be a transactional interface between programs and the DBMS. It consists usually of begin-transaction, commit, and abort commands (in some real systems abort is called rollback and begintransaction is sometimes implicit). Using these commands, the programs identify the transactional boundaries to the DBMS. This is because the DBMS cannot usually itself decide on the boundaries.

The semantics of the boundaries is that the data manipulation commands offered at the DBMS interface (e.g., select, update, delete, insert in SQL) between begin-transaction command and abort/commit are handled as one 'transaction' with 'ACID' properties by the DBMS. The term 'transaction' in this context denotes thus an execution of a sequence of data manipulation commands within the DBMS with 'ACID' properties.


The architecture model consisting of three entity types assumes that the database is only manipulated by the DBMS under guidance of the transaction programs run at the DBMS or by interactive users using the transactional interface to mark the boundaries. The programs retrieve data from the database, store data to the database, and modify its data, using the data manipulation commands offered.

Consistency. Transaction programs are assumed to be programmed in such a way that they keep the database consistent in terms of the application semantics. Especially, the data manipulation commands issued during transaction program execution between begin-transaction and commit are always assumed to have this property, called consistency (C in ACID above). A traditional transaction manager within a DBMS is built on this assumption, i.e., it does not check whether data manipulation commands issued between begin-transaction and commit during program execution left the database in a consistent state, but instead always assumes it.

Notice that consistency (C) above is a property of transaction programsor transaction specifications in a more general sense-not a property of data. Consistency is a form of dynamic consistency, because it says which state transitions in a database are allowed and preserve database consistency. Consistent database states are those which can be reached from an initial (empty) state by a sequence of consistent state transitions embedded in transaction programs.

Durability. A DBMS guarantees that the data in database persist between transactions, and that the committed data, i.e., data created or modified by data manipulation commands followed by a commit, are neither modified nor deleted by the DBMS (unless a new committed transaction has told it to do so), nor lost in crashes. This property is often called durability (D in ACID above).

Isolation and Conflict Detection Principle. The concurrent usage of the persistent data by different transactions, i.e., transaction programs in execution, is one of the main issues a transaction management mechanism must deal with. The main idea is that as long as the transactions are "isolated" (isolation, I in ACID above) from each other, their concurrently executing data manipulation commands can be allowed to proceed independently.

Intuitively, this means that transactions do not exchange or manipulate uncommitted persistent data, i.e., data that are not committed by one transaction. The basic idea is that if the transactions do not retrieve or store the same persistent data items, then there cannot be any problems. This, as well as the opposite, dangerous situation can be detected by a DBMS, because it has a full control over the data in the database. should there be problems, appropriate measures can be taken to keep the database consistent. We call this the conflict detection principle. All concurrency control algorithms assuming consistency defined as above are based on this observation.


Underlying this conjecture is the consistency property above; a transaction program execution keeps a database consistent, and if a corresponding transaction updates, inserts or deletes data items constrained by static or dynamic consistency constraints, then it must retrieve and update, insert and/or delete as many of them as is needed to ascertain that all constraints are satisfied and the database thus remains consistent upon commit. Thus, necessarily, two consistency-preserving transactions might jeopardize database consistency only if they access the same data items concurrently, i.e., while both are active. We come back to this issue in the sequel after we have introduced a more exact model of transactional computations below.

Atomicity. The other main issue in transaction management concerns dealing with transaction or system crashes. Such crashes cause several types of problems, maybe the most common of them being that a transaction program execution is interrupted when some changes have already been done to the database, but not all the required ones. Thus, the transaction within the database is incomplete and the database might be in an inconsistent state.

In this respect the traditional idea of atomicity property (A above in ACID) is that a transaction should happen completely or not at all. Operationally, from database management system point of view, atomicity means that all effects of commands of committed transactions must be stored persistently and effects of commands of incomplete and aborted transactions to the persistent data and other concurrent transactions must be made non-existent, if necessary. This activity is called (backward) recovery.

From user's point of view, atomicity simplifies the programming as the DBMS always takes care of incomplete transactions by cleaning their effects from the database, and restores a consistent database state after a crash or after an abort is issued by a program. Conceptually, a DBMS issues a bunch of abort commands during crash recovery and uses the backward recovery algorithm to implement the aborts. The same recovery mechanism can be applied in the context of an abort command issued by the transaction program.

Notice that abort and commit are asymmetric commands in the sense that commit can usually only be issued by a transaction program, whereas the DBMS can issue an abort at any time. The reason is the consistency (C) assumption; only the transaction program in execution (or a user) knows when the database is in a consistent state. This is signaled by issuing the commit command to the DMBS at the transactional interface.

Transaction Management based on ACID. The ACID properties are an archetype of properties of transactions. Consistency is attributed to programs, or users in an interactive usage, other three properties should be provided by the DBMS. Thus, the goal of a transaction management mechanism is to guarantee atomicity, isolation, and durability for program executions. Because the mechanism is embedded into a general-purpose DBMS, it is reasonable to seek concurrency control and recovery algorithms which do not depend on appli-


cation semantics. There are many excellent books that describe this work in detail (see e.g., [Gray and Reuter, 1993, Bernstein et al., 1987, Papadimitriou, 1986, Bernstein and Newcomer, 1997]).

Dependencies within ACID. It should be observed that the ACID properties are not all independent, except in the case of consistency, which is independent of the others. Relaxing too much isolation might lead to a situation where either atomicity can not be guaranteed, or durability is jeopardized (if one transaction, say Tl is recovered backwards to guarantee that its effects are abolished, the results of another, committed transaction, say T2 , must be partially overwritten, i.e., they are lost; or then the effects of Tl remain in the database through T2 which read "dirty data" from Td. This happens if non-recoverable histories in the sense of [Bernstein et al., 1987] are allowed. We have below a more elaborate example on this in Section 3.2.2, with history H7 •

If durability, in turn, can not be guaranteed, atomicity could be jeopardized, as not all results of a transaction would be reflected into the database. For instance, transaction T might update data items X and Y, and commit, but if the system could only update X and leave Y untouched (due to a crash), T's effects would be only partially reflected to the database; T's atomicity would be jeopardized. This is why a DBMS always guarantees durability, before it returns the call for a commit command with a positive acknowledgement.

3.2.2 The Read/Write Model

The persistent data are explicitly or implicitly referenced in each of the four ACID properties. This poses an important requirement for the more exact modeling of transactional computations: the persistent data are the central focus.

The ACID properties remain rather intuitive without a more exact computational model. A straightforward approach is to view the data as a passive component and operations manipulating it as active components. What should then be the operations manipulating the data? Could they be any operations, like OP(X), OP(Y), where X and Yare their parameters? They would have the drawback that automatic scheduling might be highly inefficient, because an automatic scheduler within the DBMS could only allow serial histories [Papadimitriou, 1986], if it knew absolutely nothing of the semantics of the operations, in order to ascertain that the database remains consistent.

R, W, C, and A Operations. For the reasons above, more semantics is assumed of the basic modeling operations. Too complicated semantics, however, are unmanageable, because the computational complexity of the algorithms deciding which interleavings of the operations to allow, which to prohibit grows rapidly with the complexity of the semantics. For example, predicate locks suggested in [Eswaran et al., 1976] as a means to master concurrency control


have turned out to be impractical also for this reason; deciding whether two SQL commands conflict, i.e., access the same data items, costs too much, if it is based on the predicates in the where-clause.

Because the commands and their parameters at the relational DBMS interface are too complicated to be used as a basis for transaction management, one must go deeper in the system functionality. The usual choice are Read(X) and Write(X) operations at the bottom.

The former reads a persistent data item (on disk) with identifier X leaving its current value unchanged. Read(X) models movement of persistent data to the internal buffers of the transaction program. Thus, after such an operation there are two copies of the value of data item X, one persistent, one volatile at the disposal of the transaction program.

Write(X) models update-in-place operation, which replaces destructively the old value of data item X (on disk) with a new value residing within an internal buffer of a transaction program. If two operations Writel(X) Write2(X) are performed in this order, the value written by Writel(X) is overwritten destructively by W rite2 (X).

Usually, the operations with the above semantics are given shorter notations, like R(X), W(X) and they are indexed by the unique transaction identifier, like Ri(X), Wj(X), indicating the transactions Ti and T j they belong to.

Commit and abort are modeled implicitly (or as a special W operation) [Papadimitriou, 1986] or explicitly as C i or Ai [Bernstein et al., 1987].

What exactly has been and should be abstracted in order to set up a complete formal computational model based on Rand W operations? All other functions of the DBMS, except transaction processing. From the transaction processing functionality all details except the resulting R/W sequences should be suppressed, including the decomposition process of the higher-level commands which are offered at the DBMS interface (like update,delete,insert,select of SQL) into the sequence.

The above higher-level commands can in general not directly be modeled in the R/W model, e.g., by replacing select by R and others by W in a (high level) command sequence. Rather, their decomposition into Rand W operations must be considered. The decomposition of such a command into a R/W sequence must namely access all those persistent data, including indices, which are necessary for maintaining the database consistency, as discussed above in Section 3.2.1. For instance, an update command always contains one or several Rand W operations in its decomposition, and realization of the delete and insert also often read an index record or other persistent record. Each of the three "updating" higher-level commands performs at least one W operation on a persistent (index) data item that necessarily conflicts with other concurrently active R and W operations decomposed from a command accessing such a part of the database that might jeopardize the consistency of the data. In this way also the phantom problem of dynamic databases can be understood (see [Bernstein et al., 1987], p. 64 for details).


Thus, for the purpose of transaction modeling, the functionality of the DBMS is modeled only through its results, the resulting RjW, C(A) sequence, where e.g., the borders between different command executions belonging to the same transaction are not visible. Second, the real time to perform the decomposition and the point of time when the transaction executes is of no importance. Only the temporal order of RjW, C(A) operations is important, because it determines in which order the persistent data are manipulated. Based on these ideas one can define formal (RjW) transactions.

Formal R/W Transactions. A formal (R/W) transaction Ti is a finite sequence-or a finite partially ordered set [Bernstein et al., 1987]-of Ri(X) and Wj(X) operations, possibly closed by Ci or Ai. If Ci or Ai is included into a formal transaction it is complete, otherwise it is incomplete.

Often certain syntactic correctness criteria are imposed on the formal transaction, like that the same data item X can be read or written at most once, that Ai and Ci must follow all other operations, and that both Ai and Ci cannot occur in a (formal) transaction.

A history H over transactions Tl ... Tn is an interleaved sequence-or a combined graph-of R and W operations occurring in T1 •.. Tn such that it contains all operations of each of T1, T2 , ••• Tn and that internal (partial) orders of each of T1, T2 , ••• Tn are contained in H.

A history contains all interactions between transactions, i.e., transactions do only exchange data with the help of R and W operations occurring in it and there are no other exchanges.

Durability and Consistency in the RjW Model. The ACID properties are usually modeled in the following manner. Durability is modeled by stating that if Wj(X) is followed by Ri(X) in H and there is neither Wk(X) (k f:. j) nor Aj between them then the value read by Ri(X) is that written by Wj(X). One says also that Ti reads-X-from Tj and that Ti and Tj are in reads-from relation with each other in this case. .

Consistency is embedded into the model by assuming that a committed formal transaction contains such Rand W operations that the database consistency is preserved, i.e., that the commands generated by the transaction program at the DBMS interface and their decomposition into the RjW, C sequence within the DBMS preserves dynamic and static consistency constraints (see above). Notice that a committed formal transaction thus accesses all persistent data, including indices and all control information which are part of the persistent database state and necessary for preserving the consistency (cf. above).

Isolation in the R/W Model. Isolation is usually divided into two cases, isolation in histories without failures and isolation in histories with failures. The former is tackled by serializability, the latter by recoverability [Bernstein et al., 1987] or (rollback) reliability [Papadimitriou, 1986].


Serializability of history H means that it is in some sense equivalent with a serial history Hs. Behind this idea is that if transaction programs are run one at the time, yielding a serial history Hs = TIT2 ... Tn, there cannot be any harmful interference between them. By assuming consistency of each and every formal transaction, one can easily show that the database remains correct after any serial history.

In which sense should an interleaved execution be equivalent with a serial one? The first evident problem is that in a serial history all transactions are complete, whereas in an arbitrary history H there are incomplete and aborted transactions. One cannot include incomplete transactions into a serial history without loosing its central meaning that says that all transactions in it are complete. Thus, there are two possibilities to cope with this problem. First, one can prune incomplete and aborted transactions away from H and thus obtain the corresponding serial history.

A problem with this approach is that if too much concurrency is allowed in H, also problems might be pruned. Thus, the theory might state that history is serializable and thus correct but in reality it is not (see below Hr).

Another way of dealing with incompleteness is to complete the incomplete transactions in one way or the other in order H to become comparable with a serial history Hs. We come back to this idea below in the context of atomicity.

Either by pruning or completing the incomplete transactions of H one arrives at a committed projection, C(H) which only contains committed, complete transactions of H [Bernstein et aI., 1987]. This can then be reasonably used as a basis of the equivalence relation.

What is then the equivalence relation used between C(H) representing H and a serial history Hs? There are several reasonable possibilities. View serializable histories are those where the transactions in H read the same values as in a serial history. Additionally, the final writes must be same for each data item occurring in histories. Based on the binary reads-X-from relationship above, this can be formulated by requiring that the reads-from relations between transactions are the same in both histories.

View serializability is considered to be a fundamental correctness criterion, because it guarantees the same values to be read and written in H as in Hs.

Another way of defining the equivalence is to use conflict equivalence. Two operations conflict if one of them is Wand they access the same data item (Le., Wi(X), Wj(X) conflict and Wi(X), Rj(X) conflict for any X if i i- j). Histories are conflict equivalent if they contain the same operations and order the conflicting operations in the same way. H is conflict serializable if its committed projection C(H) is conflict equivalent with a serial history Hs.

Conflict serializable histories can be characterized by acyclicity of the serializability graph SG(H) [Bernstein et aI., 1987]. This is a general result for any conflict definition which is based on commuting/conflicting operation pairs, no matter how the conflict is defined. The property is also prefix commit-closed, i.e., if H is conflict serializable, so is every prefix of H , H' and C(H') conflict serializable. The same does not hold for view serializability, unless prefix-


closedness is included into the definition as is done in [Bernstein et al., 1987]. It can be shown that each conflict serializable history in the above sense is also view serializable, i.e., it is correct in this deeper sense. The contrary is not true, i.e., there are view serializable histories which are not conflict serializable (see [Bernstein et al., 1987], p. 40).

Atomicity and Failures in the R/W Model. Atomicity is modeled by assuming that all transactions eventually commit or abort, i.e., the formal transaction eventually contains C or A. Incomplete and aborted transactions could either be (formally) pruned (or projected) away or they could be (formally) continued into completion. The former modeling approach is used both in [Papadimitriou, 1986] and [Bernstein et al., 1987].

Modeling incomplete and aborted transactions through pruning or projecting them from the history is intuitively appealing, as it corresponds to "did not happen". It must, however, be accompanied by checking whether the pruned history correctly reflects what has happened. Consider the following conflict serializable, unrecoverable [Bernstein et al., 1987] (and unreliable [Papadimitriou, 1986]) history:

By the above pruning principle, Tl must be pruned, i.e., C(H7) = ToT2 which is serial, conflict serializable in the above sense and should not have any concurrency problems. However, what really happens in H7 is different from what happens in C(H7), because T2 reads the value of Y (say 1) written by Tl and then overwrites Y by a new value (say 1+1) that depends on what Tl wrote to Y. Thus, the value of Y is 2 after H7 , but assuming the initial value 0 it is 0+1=1 after C(H7). This is counter-intuitive and evidently a flaw in modeling, as it would mean that the database state after H7 and in any continuation of it, H!" differs from C(H!,), as any committed projection prunes T2 away, but T2 results are live in H!, through Tl .

The explanation for the above phenomenon is that by pruning T2 from H7 changes the reads-from relation of H7 to a different one from C(H7). In terms of [Papadimitriou, 1986] the above history is thus not reliable, because pruning T2 changes the version function in H7 • It is still conflict serializable in terms of [Bernstein et al., 1987]. The flaw seems to be that in [Bernstein et al., 1987] the authors do not analyze for which cases the database state after H and C(H) is indeed the same for serializable histories.

Let us look shortly the completion alternative. There are two possibilities, either to continue an incomplete transaction to an aborted completion or to a committed completion. In reality, a DBMS must be prepared for a crash at any time. Thus, the completion approach models a system crash as a result of which the DBMS must complete incomplete transactions and ascertain that the results of transactions committed at the moment of the crash become and remain durable.


Because a traditional DBMS does not have any information on the application semantics, it cannot guess how an incomplete transaction would have continued in a normal case, and whether the database is in a consistent state. Therefore, it cannot continue a transaction into a committed completion. It can, however, abort an uncommitted transaction at any time. It has to keep track of what has happened so far, and based on the history known to it, it then continues the transactions to be aborted by restoring such old values to the database that the effects of the transactions are undone. Conceptually, this is backward recovery based on compensation, where the compensating operations are generated based on the R/W history known before the crash or individual transaction abort.

How could a DBMS continue Tl above in H7? The R operation need not be compensated, but the W should be. What does it mean in this context? Maybe the transaction manager should restore the database as it was before Tl changed it thus rendering "did not happen at all". In H7 transaction manager should thus restore the value written by Wo(X, Y, Z, U) for X, Y, and Z. Assuming that the recovery algorithm first reads a suitable value and then restores it by wr operation, we obtain:

H; = Wo(X, Y, Z, U)Wl(X)Wl(Y)R2(U)W2(X)R2(Y)W2(Y)C2Wl(Z)Al

Rl(WO(Z))W[(Z)Rl(WO(Y))W[(Y)Rl(WO(X))W[(X)C1

Observe that with the above idea of "did not happen at all" the results of T2 are completely overwritten by an aborted transaction, i.e., T2's durability is violated. If we use a conflict definition that captures the system generated recovery Read and Write operations W[(X) which are usual update-in-place operations, except that we know the value read and written is a particular old one, we see that H? is not conflict serializable (e.g., W1 (X)W2(X)W[(X) causes a cycle in SG(H~)).

What if the recovery algorithm would take the closest committed values before Tl in H7? In this case the initial value of Z would be restored and the results of T2 preserved:

H~ = Wo(X, Y, Z, U)Wl(X)Wl(Y)R2(U)W2(X)R2(Y)W2(Y)C2Wl(Z)Al

Rl (Wo (Z)) W[ (Z)Rl (W2 (Y)) W[ (Y)Rl (W2 (X)) W[ (X)C1

Again, H~ is not conflict serializable in the sense of the above conflict definition, so there is something wrong with it. Indeed, as in the pruning approach, the results of Tl are preserved through T2 in H~ although Tl should not have happened.

The completion approach can be better modeled as a versioning approach, because the backward recovery algorithm must read older versions of data items from history. A more appropriate serializability theory for the completion approach is therefore that developed for multiversioning of data (see, for example, [Papadimitriou, 1986, Bernstein et al., 1987]). Notice that such a serializability concept would be a uniform one in the sense that it would capture all concurrency-related problems as serializability problems, including the


crash-related anomalies. It would differ from another existing uniform concept (roll-back) reliability in the modeling incentive, pruning versus completion. A more detailed treatment of this approach is given in [Veijalainen and Wolski, 1997] (see also [Vingralek et al., 1997]).

Computational Complexity of Serializability and Reliability. From computational complexity point of view the set of reliable histories is PSPACEcomplete and the set of view serializable and rollback reliable histories are NP-complete, whereas the set of conflict serializable histories is polynomial [Papadimitriou, 1986]. Thus, all practical concurrency control algorithms for the R/W model are conflict-based.

Coming back to the intuition about isolation, rigorous histories [Breitbart et al., 1991] do not allow uncommitted data to be read or overwritten. They are automatically conflict and view serializable and reliable. This shows that the complexity of the above serializabilities allowing more interleavings than conflict serializability is caused by either reading or overwriting uncommitted data, or both.

3.3 MAIN TECHNIQUES TO IMPLEMENT THE ACID PROPERTIES

The ACID properties expressed through the R/W model have been the basis to develop techniques and algorithms which then guarantee the correct functioning of the DBMS. In the light of the discussion of Section 3.2.1 this requires guaranteeing reliability (or at least roll-back reliability) [Papadimitriou, 1986]-or view serializability and recover ability [Bernstein et al., 1987]-and durability.

3.3.1 Achieving Durability

As discussed above, durability can be violated by allowing too much concurrency, especially in the presence offailures (see history H1 above). This problem can be avoided by the concurrency control and recovery algorithms (see below). Other problems are system crashes and media failures. In order to recover from system crashes a DBMS must be equipped with a persistently stored log which records the above formal history in a suitable form.

After a system crash the log is scanned by recovery algorithms and a correct database state is restored by re-executing W operations of some committed transactions if necessary, and generating and executing the compensating R/W operations to restore some earlier database state for incomplete and aborted transactions (see Section 3.2.2). What needs to be done depends on whether uncommitted data is allowed to be written in database and whether the DBMS allows committed data in log which is not written into the database.

A detailed treatment of the traditional recovery issues is given e.g., in [Bernstein et al., 1987]. A formal treatment of a successful recovery method ARIES [Mohan et al., 1992] can be found in [Kuo, 1996].

The log can also be used to repair damages caused by media failures to the persistent database state; the Write operations of the committed transactions


are re-executed from the log. Another means to improve database durability and reliability is to replicate database or parts of it.

3.3.2 Techniques for guaranteeing Serializability and Recoverability

Historically, one of the first developed mechanisms for concurrency control was locking. A transaction requests locks on resources it is using. If the lock is gtanted by the DBMS transaction continues running, otherwise it is suspended until the resource is unlocked. A lock is traditionally set on a data item accessed by a R or W operation, but they can always be understood as attached to operations, i.e., as operation locks. In the simplest form a lock is exclusive in which case only one operation at a time can access the resource. The R/W model makes possible Rand W locks, which are granted/denied according to the conflict relationships of the Rand W operations. Thus, there can be several R locks on the same data item.

Locking policy is the other corner stone of a locking scheme. It says how the locks are requested and released by different transactions. In two-phase locking (2PL) no transaction releases a lock before it has got all locks granted it will request. This policy guarantees conflict serializable histories, but not recoverable histories. In Strict 2PL the locks are released at commit or abort. This policy only allows rigorous histories which are conflict serializable and recoverable and avoid e.g., cascading aborts.

The nuisance caused by locking is a deadlock, i.e., a situation where two or more transactions wait circularly for each other to release a lock. There is large body of literature on different locking policies and deadlock handling (see, for example, [Gray and Reuter, 1993, Bernstein et al., 1987]).

Time-stamps are another mechanism to protect against concurrency anomalies. A time-stamp is generated by the DBMS upon issuance of a begintransaction command and it is attached to the operations of the transaction. Time-stamps must increase with time and they must be belong to an ordered domain. The basic idea is that conflicting operations are processed in the timestamp order. The data items are marked by the time-stamp of the last and W operation that read or wrote it. The approach suits well for versioning of data. It guarantees conflict serializability.

Different variations of time-stamping are possible. The basic time-stamp ordering allows operations to proceed and access the data items provided no conflicting operation comes "too late", i.e., with a smaller time-stamp than what has been already recorded at the data item. If this happens the transaction has to be aborted and restarted with a larger time-stamp. Depending on the detailed implementation, this policy allows or does not allow recoverable histories (see [Bernstein et al., 1987] for details).

A conservative time-stamp ordering tries to ascertain that it does not need to abort transactions, i.e., it will let the operation wait until it is sure that no operation with a smaller time-stamp will come. In fact, it schedules all operations, whether conflicting or not, in the time-stamp order. This policy


allows only serial histories and the scheduler can get stuck in case of failures of a TM in the distributed case.

Serializability graph checkers are techniques that are based directly on the characterization of conflict serializability through the acyclicity of the serializability graph SG(H). They guarantee conflict serializability, but not automatically even recoverability of the history.

All concurrency control techniques can be used in an optimistic or pessimistic way. In the former case the transactions are allowed to proceed freely until commit (or abort) and correctness of the resulting history is checked as part of the commit/abort handling. If the resulting history was not serializable (and recoverable), the transaction commit is denied and transaction aborted. Depending on the policy enforced, also other active transactions might have to be aborted that read the (dirty) data written by the transaction to be aborted. This results in so-called cascading aborts.

Pessimistic approaches try to ascertain that the serializability graph of the (entire) history is at any moment acyclic and the history recoverable in the sense of [Bernstein et al., 1987]. Thus, they delay operations and possibly abort transactions should the conditions be threatened by the next operation. Typically locking is used to delay the operations during run-time.

3.4 GENERALIZING ACID

The ACID properties can be (intuitively) formulated without the R/W model, although currently the term "ACID transactions" often refers to conflict serializable and (at least) recoverable transactions in the sense of the R/W model. Computations can be regarded to have ACID properties even if they were not "ACID transactions" in the above narrower sense, as long as they are "atomic" and "isolated" in a more general well-defined sense. We discuss below how especially atomicity and serializability can be generalized.

The R/W model can be regarded as a "flat" model, as it models transactional computations through sequences or partially ordered sets of elementary R and W operations with well-defined semantics. In a real DBMS the interfaces used by the transaction programs offer high-level commands akin to those of SQL in relational databases, or methods defined in the object schemas in objectoriented databases. The operations offered at interface must be decomposed by the DBMS into elementary Rand W operations (or operations having their semantics), before the results obtained for R/W model can be used.

Transaction processing in distributed databases introduced at the end of 1970's challenged in particular the flat R/W model, because it is evident that the high-level commands must be decomposed to be run as distributed transactions at different sites. Decomposing the higher level SQL commands by the DBMS into elementary R and W operations run at different sites and managing them correctly is a non-trivial problem. A distributed transaction has indeed a more complex structure than a centralized transaction.


In a distributed system architecture it is reasonable to introduce subtransactions that run at different sites under different pieces of software, but are each a part of a single global transaction. Thus, two levels of transaction processing can be identified, a global level and a local level. A very natural way of modeling such transactions is to use a transaction tree, where the root represents the global transactions and subtransactions are modeled as subtrees. The subtrees may have different names, like local subtransaction or global subtransaction, depending on the level they occur at.

Among the early published works for structured transactions, where transaction trees are used, were Ph.D. thesis work by Reed [Reed, 1978] and Moss [Moss, 1982] at MIT. According to the latter, the idea of nested transactions came from [Davies, 1973]. Often, the hierarchical structuring of transactions is called nesting, even though the model would not support the properties of the original nested transactions.

In the simplest transaction tree each subtransaction and the global transaction are empty nodes, and the leaves are Rand W operations with the standard semantics. Transaction trees have been used to model more accurately centralized transaction management in order to cope with semantics of operations. In many cases they may also have more levels and contain data manipulation or locking operations and/or predicates necessary for the proofs in the higher level nodes (see, for example, [Veijalainen, 1990, Weikum, 1991, Veijalainen and Wolski, 1992, Korth and Speegle, 1994]).

A transaction tree makes it in principle possible to treat the parts of the tree as separate units with separate transactional properties. Thus, subtransactions can have isolation properties that differ from each other and from those of the root. This allows an increase in intra-transactional and inter-transactional parallelism. The subtransactions can also have atomicity properties different from each other and from the root. And finally, whereas a flat transaction is the unit of isolation and atomicity as a whole, these properties can be separated in a hierarchically structured transaction; The entire transaction can be a unit of atomicity, but at the same time the subtransactions can be units of isolation.

3.4.1 Generalizing Atomicity

Distributed transactions brought up the issue what is the precise semantics of the original intuitive atomicity definition 'transaction should happen completely or not at all". Each subtransaction can fulfill the basic atomicity with respect to the local data, but still some of them might commit and some abort. Thus, the global transaction might become partially persistent, partially its effects on data might be abolished. This problem can be fixed by requiring that all subtransactions either commit or abort. To enforce this rule, a two-phase commit protocol (2PC) (or three-phase commit protocol, see [Bernstein et al., 1987]) has to be used within the DBMS and the transactional interface of the DBMS at sites should support the Prepare command.


The 2PC protocol has primarily nothing to do with the database state; it only guarantees that in a distributed database subtransactions agree on a common decision, be it then abort or commit. 2PC together with the assumption that each DBMS at site behaves according to the (R/W) atomicity, as discussed above in the context of R/W model, guarantee that the original "either happens completely or not at all" semantics with respect to data is achieved.

Generalized Atomicity. The (R/W) atomicity can be generalized and formalized using for example some form of a transaction tree, or other formal mathematical structure, such as a directed acyclic graph (DAG). One needs to define when such a structure is in a consistent/inconsistent state, when it is in an intermediate/end state, when such a structure in an end state models a semantically unsuccessful transaction, and when a successful one.

Generalized atomicity means that the DBMS (or another transaction management system) is able to guarantee that any transaction reaches a consistent successful or unsuccessful end state, i.e., the transaction tree (or other structure) modeling the computation will be in this type of state at the end.

In a successful end state the transaction has succeeded semantically, i.e., it has done, say, the Hight and hotel reservations and necessary fund transfersmaybe after having checked several airlines. In an unsuccessful end state it has tried but has not succeeded in some essential part of the overall task, e.g., in a hotel reservation and it has compensated those subtransactions it already performed successfully. In the case of a successful airline reservation compensation means canceling it.

Generalized atomicity at the RjW level. As an example notice that the (R/W) atomicity based on data can be captured by the above new definition; Consider the following history:

H~ = Wo(X, Y, Z, U) Wt{Xl ) Wt{Yl )R2 (UO)W2 (X2)R2 (Y2)W2 (Y2)C2 Wl (ZdAlRl (Zo)W{(ZO)Rl (Yo)W{(YO)Rl (Xo)W{(Xo)Cl

which is as history H~ above, but Xj is used to denote the version of X written by Wj(X). Thus, it can be read by Ri(Xj) and written back to the database by W[(Xj) during recovery.

Let us define: A (formal) fiat transaction is a sequence of R, W,A,and C operations, where A and C occur at most once. A transaction is complete and committed provided it is closed with C, and complete and aborted if it contains A and is closed with C. It is incomplete ifit is not closed with C. It is in a consistent state if does not contain A or it contains A and for each W operation preceding A it contains a compensating ROWrO operation following A. Otherwise it is inconsistent.

Now, the generalized atomicity says that the DBMS always guarantees that any transaction is eventually run into a consistent completion. Thus, if the transaction is successful, i.e., committed in this case, it contains all R and W operations preceding C. If it is unsuccessful, i.e., aborted, it contains a


compensating W operation for each W it performed before abort occurred. Notice that the characterization of (RjW) atomicity is completely syntactic above. Therefore, this base model based on the RjW model can be attached to other atomicity definitions as its lowest layer if referring to data base state is essential in the generalized atomicity concept.

It should also be observed that the atomicity characterization above ignores concurrency anomalies between transactions; in H~ T2 is atomic, as well as T1 ,

but T2 is partially overwritten by the recovery of T1 • This is considered solely as concurrency control problem, not as atomicity problem in this approach.

Generalized atomicity and structured transactions. As another example consider a distributed transaction with subtransactions. The structure is a two-level tree with R, W, A, C operations as leaves and C and A occurring at intermediate and root level. The consistency requirement for the transaction tree is that if C occurs at the root then A must not occur at any level below, and if A occurs at the root then C must not occur at the intermediate level. Additionally, the above requirement about (RjW) atomicity at the leaf level must be valid. The structure is complete if C occurs at each level or if A occurs at each level and C occurs at the lowest level.

As a third example of transaction tree we take a banking database with several currencies. If a customer sells 10000 dollars and buys Finnish marks, an abstract funds transfer FT(10000, account - cust - usd, account - cust -fim) is performed. In reality, it must necessarily be divided into two separate funds transfers according to currencies:

FT1(10000, acc - cust - usd, acc - bank - usd)

FT2(5.42 * 10000, acc - bank - fim, acc - cust - fim)

where 5.42 is the current (but daily varying) exchange rate between the Finnmark and the US-dollar. These two funds transfers can be performed within one big (RjW) transaction or separately as two (RjW) transactions with ACID properties and in any order. The database is consistent after each of them, because there are no permanent consistency constraints between the Finnmark and US-dollar parts.

By these principles and the general atomicity rule, the transaction either ends in a "committed" state where all subtransactions are committed, i.e., successful, or in an "aborted" state where they all have been aborted. In the latter case also their effects have been abolished from the (local) databases, provided the (RjW) atomicity is guaranteed for the subtransactions by the local DBMS.

Generalized atomicity and compensating subtransactions. In a more general case the transaction tree can contain compensating subtrees modeling backward recovery and contingency (or alternative) subtransactions modeling forward recovery, which are performed if the original subtransaction did not succeed. For these trees more complex rules concerning when they are consis-


tent and complete exist. For instance, the requirement that a compensating or contingency subtransaction should have the same structure as the original subtransaction can be relaxed. We treat some of the possibilities below in Section 3.5.

Atomicity beyond generalized atomicity. It is known that in extremely autonomous distributed environments a global transaction management system cannot guarantee generalized atomicity, because it cannot successfully perform compensating or alternative subtransactions (see, for example, [Veijalainen, 1990, Veijalainen and Wolski, 1992]). This raises the question of relaxing even generalized atomicity further. It can be done at least in two ways. First, one can investigate whether the computation has intermediate states, which have some "good" properties where the transaction could be interrupted with less damages than in another state, and could be finalized for example manually, or continued by invoking another transaction. A typical example is an intermediate transaction state, where the database is left consistent even if a transaction has been performed only partly. The currency buying example above is a typical case of such a situation.

In general, one can show that if the database is indeed divided into consistency partitions between which there are no static consistency constraints, the transactions can be decomposed according the borders to subtransactions that can be executed and committed/aborted separately. The global atomicity rule then tells when the global transaction tree can be considered consistent and the system tries to enforce it by repeating failed parts.

Second, one can admit that the end state is indeed not reachable and go e.g., in the direction of probabilistic (or fuzzy) atomicity. In other words, when it is evident that an end state is not always reached, one can ask with which probability a consistent end state is reached and with which probability the transaction eventually terminates in a state other than an end state. In some cases repeated compensation or re-execution efforts increase the probability that the atomicity will be reached (see, for example, [Veijalainen and Wolski, 1992]) but there are cases, where an operation simply cannot for semantical reasons be compensated at all, and thus the global transaction cannot be rolledback. A more thorough analysis for latter case is presented in [Veijalainen, 1990]. Relaxing atomicity in general and the probabilistic (and fuzzy) atomicity in particular are issues for further studies.

3.4.2 Generalizing serializability

Relaxed R/W serializabilities. First, a class of generalizations is based on the R/W model. In these it is always question of defining a new equivalence relation between an interleaved and serial history, as compared to conflict or view serializability. One of the oldest concepts was state serializability [Papadimitriou, 1986]. Newer examples are R/W conflict-based equivalencies quasi-serializability [Elmagarmid et al., 1990], two-level serializability [Korth


and Speegle, 1994], multidatabase (recovery oriented) serializability in [Veijalainen and Wolski, 1992] and M-serializability [Rastogi et al., 1993].

Serializabilities based on transaction trees. The transaction trees can be also used to generalize serializability. One has to first define a serial forest and then a serializable forest which is in some sense equivalent to the serial forest.

There are two aspect to be considered, when is a transaction tree itself serial and when is the forest serial. The former is required in order to define the allowable intra-transactional interleavings of subtransactions, i.e., intratransactional parallelism. Nested transactions of Moss [Moss, 1982] were one of the first approaches where this was studied and also locking scheme was developed that guarantees the desired level of concurrency.

Another well-known example is multi-level serializability [Weikum, 1991]. In this, the idea is that transaction trees are of the same height and that each leaf, i.e., R, W, C operations are at the same level. Intra-transactional parallelism is increased by higher level conflict/commutativity definitions. That is, even if two higher-level operations have conflicting operations at R/W level, they might for semantic reasons commute (see below). Thus the order of the subtransactions representing their R/W decomposition could be changed in the transaction tree. An inherent feature of this approach is that atomicity of the transactions is based on compensating operations at higher level than at the R/W level, because non-RW-serializable histories are allowed at the lowest level and state-based recovery cannot be used (see Section 3.4.3). We treat this model more precisely below.

In both above models the root transaction preserves similar serializability properties against other roots as in the flat model. One could thus project the higher levels away and treat the leaf-level Rand W operations like in the flat model, as concerns the inter-transactional parallelism. This concurrency restriction is remedied in the open nested transaction model where the same conflict/commutativity principles are applied both to intra- and inter-transaction concurrency.

Finally, a quite elaborate serializability concept for inter-transactional purposes is that published in [Beeri et al., 1989]. The idea is to present a rule, as when a transaction forest can be transformed by a sequence of pruning and swapping steps into a serial forest. The difference to the above models is that the serial forest obtained might be structurally different from the forest to be tested.

3.4.3 Generalized models, generalized problems?

The modeling problematics of incomplete and failed computations is of general nature and should be solved in the context of every serializability concept, because serial histories cannot by definition contain incomplete transactions. This does not change, even if the transaction trees or other structures are used


to model individual transactions. Should an incomplete tree be pruned from the forest corresponding to a R/W history, or should it be completed using appropriate principles? Basically, a (formal) completion of a transaction tree into an unsuccessful end state should always be possible, similar to the flat transactions, by using compensating operations or compensating subtransactions. After the completion one can again ask, whether the forest so obtained is serializable according to some serializability criterion.

Conflict detection. There is one issue that should be kept in mind about conflict-based serializability, when one generalizes it. In R/W model conflict detection takes a constant time, because one only needs to decide whether two simple (integer) values X and Y in OP(X) and OP(Y) are the same. Why doesn't, for example, predicate locking [Eswaran et al., 1976] work, it is in any case a conflict-based concept? The problem is that conflict detection is much more involved than in case of R and W operations, as one must determine whether two predicates P(X) and pry) intersect or not. Depending on the predicates allowed, this problem can be unsolvable, NP-complete, or polynomial [Hunt and Rosenkrantz, 1979]. This is exactly the reason, why generalized conflict concepts require users to explicitly define, when two higher-level operations conflict, when they commute. This information for each operation pair is given to the run-time system in form of conflict tables or similar constructs. We discuss the different transaction models using this idea below.

Compensation as a backward recovery mechanism. A similar, but not identical problem as above with conflict detection, there is with compensation. As discussed above, in R/W model the run-time system is able to automatically generate the compensating operations: read an old value from the log and write it back to the database for each write operation to be aborted. This principle works if not "too much" concurrency is allowed (see H; above in Section 3.2.2), i.e., the R/W histories should not be non-recoverable [Bernstein et al., 1987]. Increasing concurrency leads to the situation, where the DBMS cannot anymore automatically generate the compensating operations. To restore the old values to the database in an unrecoverable or non-R/W-serializable history results usually in anomalies and the database is corrupted.

How can compensating operations be defined. The general setting of compensating operations is as follows. Assume the following operation history:

OP = ol(inlloutdo2(in2,out2)···

oi(ini, outi)Oi+l (ini+ll outi+1 ... ( . t) comp(. comp tcomp ) 0i+k ,ni+k,OU i+k 0i ,ni ,OU i

where k ~ 0 and the operations have a more complicated semantics than Rand W, the compensating operation of OiO, o~omp(in~omp, out~omp) should bring the database into such a state that


• in any history 0 P' = Oi+k+20 . .. Oi+k+r 0, r ~ 0, occurring as a direct continuation of OP, i.e., in some OP" = OP OP', the effects of OiO are (semantically) invisible; and

• in 0 P', the effects of

on a database state are not (semantically) changed by o~omp 0 in 0 P' .

For k = 0, one gets the special case where the compensation follows immediately 0i 0 in 0 P". The latter condition is trivially satisfied, because there are no operations between OiO and o~ompo. A sufficient condition for a compensating operation to exist is that it (semantically) commutes with the intervening operations for any k, k ~ ° with respect to the database state and that it compensates 0i if executed immediately after it. (Semantic) commuting of Oi(ini, outi) and oj(inJ,outj) means that in execution orders oi(ini,outi)Oj(inj,outj) and OJ (inj, outj )Oi(ini, outi) the output parameter values outi and outj are the same (semantically equivalent) irrespective of the preceding history, i.e., in any state. We consider here the output parameter to contain also the entire abstract database state.

Another sufficient condition is that the operation 0i to be compensated (semantically) commutes with respect to the database state so that it can be moved to the right in the intervening history, to precede o~ompO.

By using the word semantically above in parenthesis we refer to the possibility that the database state can be changed by compensating operations, but the changes must be such that the following operations consider the state to be semantically equivalent with the state preceding the compensation. A special case is the abstract state. Semantically invisible means that the state after the compensating operation is deemed semantically equivalent in OP' with the state where 0i was not performed but the intervening operations were performed. What is a reasonable equivalence definition depends on the concrete set of operations. A special case is identity.

The above general scheme can be restricted, as is done for example, in [Garcia-Molina, 1983] where the histories are required to be semantically consistent. In this approach it is required that the sensitive intervening operations should not expose the results of 0i if the latter will be compensated. Thus, the transaction management mechanism must prohibit such intervening transactions in some manner.

Can a more general concept of compensation than restoring old values be defined in such a way that a compensating operation o~omp (in~omp, out~omp) can be algorithmically computed during run-time for any operation OiO occurring in an arbitrary operation history?

The answer seems to be open. All transaction models using higher-level compensating operations or compensating subtransactions resort to the assumption that compensating operations/subtransactions are specified to the run-time system by users so that it is enough to only invoke them with certain


parameters if needed. The actual semantics of what compensation means is outside the scope of the run-time system. This approach is nicely discussed in [Garcia-Molina, 1983). We review below several models based on this assumption.

3.5 ADVANCED TRANSACTION MODELS

3.5.1 Semantics-based Concurrency Control

Usually, the semantics of shared data in cooperative applications is much more complex than the read/write semantics used by conventional database transaction model. As a result the concurrency control policies of these models is more conservative than necessary because they do not take into account the semantics of the data objects accessed by the application.

Semantics-based concurrency control was first proposed in the context of abstract data types [Korth, 1983, Schwarz and Spector, 1984, Weihl, 1988) and later adopted for object-oriented DBMS. Its main goal is to achieve a higher degree of concurrency than using the traditional R/W model. Additionally, the semantics of data objects can be used to provide increased availability of data and more flexible recovery. For an overview of semantics-based concurrency control techniques we refer to [Ramamritham and Chrysanthis, 1997).

The idea behind semantics-based concurrency control is as follows. By abstracting from the low-level details, i.e., the concrete implementation in the database, and by exploiting the high-level semantics of data objects and operations, certain conflicts that might occur between decompositions of the operations into elementary R/W sequences can be ignored. The most commonly used approach to capture the semantics of data objects is to specify commutativity relations among operations defined on single data objects. Informally, two operations commute (do not conflict) if their effects on the state of the object and their return values are the same regardless of their execution order. This ensures that no transaction can observe a difference between both execution orders.

When a transaction requests the execution of an operation, this request can be granted if the operation commutes with all other operations of uncommitted transactions. This policy ensures the semantic serializability of concurrent transactions-not at the level of disk page accesses but on the level of higherlevel operations. Of course, the system has to ensure that both operations are executed in such a way that their decompositions into two R/W sequences are conflict serializable, but it does not matter which operation precedes which in the corresponding serial decomposition. If we allow only commuting operations to execute concurrently, this prevents cascading aborts [Ramamritham and Chrysanthis, 1997). Thus, (a variant of) ACID properties of transactions can be easily preserved while allowing more concurrency. The price to be paid is the specification and test of the commutativity of operations by users.

Weihl [Weihl, 1988, Weihl, 1989) distinguishes between backward commutativity and forward commutativity. The difference between these two notions


of commutativity is the underlying execution model or recovery policy. Backward commutativity is applicable to an update-in-place execution model with log-based recovery. Forward commutativity is applicable to an deferred-update model with intention-list-based recovery and to optimistic concurrency control.

In addition to commutativity, other (non-symmetric) semantic relationships have been proposed in literature, namely invalidated-by and recoverability. These relationships drop the requirements on the equivalence of states of the objects and consider only the results of operations externalized to the applications, i.e., the output parameter values after the execution. In [Herlihy, 1986, Herlihy, 1990], the invalidated-by relationship has been introduced for optimistic concurrency that is a special kind of the serial-dependency relationship. Recoverability [Badrinath and Ramamritham, 1992] allows non-commuting but recoverable operations to be executed concurrently and ensures that there is no cascading abort if transactions are committed in the same order as the operations were executed.

Semantics-based concurrency control does not support cooperation directly but it achieves a high degree of concurrency. Thereby, it reduces the probability of long waits or aborts which is important where transactions are of long duration. The commutativity relations will also be an element of the TRANSCOOP cooperative transaction model, described in Chapter 7.

3.5.2 Multi-level and Open-nested Transactions

The basic goal of multi-level transactions [Weikum, 1991, Weikum and Schek, 1992] and its generalization to open-nested transactions [Weikum and Schek, 1992, Muth et al., 1993] is to enhance inter-transaction parallelism and to allow for a finer recovery granularity. This is achieved by modeling a transaction as a tree of subtransactions, by exploiting the semantics of database operations, and through recovery by compensation (like in SAGAs [Garcia-Molina and Salem, 1987]) rather than by state-based undo.

A multi-level transaction has an implicit internal structure where the nodes in the transaction tree correspond to executions of database operations at particular levels of abstractions in a layered database system. Both subtransactions and actions (at the leaves of the tree) are considered atomic. All multilevel transactions trees have to have the same depth which equals to the layers in the system. Multi-level serializability replaces traditional read/write serializabilityas correctness criterion while preserving generalized ACID properties of transactions. The idea is to exploit the semantics of database operations in level-specific conflict relations based on commutativity. Commutativity at a specific layer refers to abstract database states and not to concrete states, i.e., operations at a lower layer are allowed to see differences. Conflicts at a lower layer can be ignored if two operations at a higher layer commute with respect to the abstract state. Since many concrete states at a lower level may correspond to the same abstract state at a higher level, multi-level serializability allows more concurrency than "flat" serializability.


As a consequence of the early visibility of modifications to commuting subtransactions, the abort of a subtransaction can no longer be implemented by restoring the database state directly to the state before the subtransaction. An already committed subtransaction S has to be undone by its compensating subtransaction that semantically undoes the effects of S, i.e., restores the database to the same abstract state as before the original transaction. Before a subtransaction S can be compensated, first all other subtransactions of the same transaction executed after S have to be compensated in inverse order. This is similar to the approach used in SAGAs. The compensating subtransactions are fully embedded in the concurrency control mechanism, i.e., they are executed as regular transactions in this respect. The semantic lock for the compensating subtransactions has to be granted before the execution of a specific subtransaction. This ensures that the compensating subtransaction will be executable, if needed and the generalized atomicity property of transactions is thus preserved (the transaction tree contains all compensating transactions necessary in case of roll-back). At the same time, the semantic lock for compensating operation guarantees multi-level serializability. Preparing for possible compensation reduces concurrency at the same time.

For open nested transactions transaction siblings in the transaction tree are allowed to have different nesting depth. Open nested transactions are wellsuited for object-oriented DBMS. The dynamic method invocation hierarchy can be transformed to an open-nested transaction and the semantic properties of methods can be exploited on a per object basis. This is similar to semantic concurrency control as described above. In open-nested transactions, semantic serializability [Muth et al., 1993] replaces multi-level serializability.

Long running transactions are well supported by open nested transactions because of the high degree of parallelism. In addition to this, the model provides a finer granularity of recovery units (partial rollback). Nevertheless, sharing of volatile private data is not possible because the model sticks to a variant of serializabilityas its correctness criterion. User-initiated undo can be implemented by exploiting the commutativity relations and the compensation mechanism. In [Weikum and Schek, 1992], some further extensions of open-nested transactions are outlined to adapt them to specific needs of an application.

In the following Subsections we discuss the transaction models especially developed for cooperative environments.

3.5.3 Dynamic Restructuring of Transactions

The split/join transaction model [Pu et al., 1988, Kaiser and Pu, 1992] was developed for open-ended activities characterized by uncertain duration, unpredictable developments, and interactions with other concurrent activities. The model addresses cooperation among users by supporting the dynamic restructuring of ongoing transactions. A split command allows to split a running transaction into two transactions while a join command allows to incorporate two transactions into one transaction.


The correctness criterion used is R/W (conflict) serializability of transactions to be committed. In contrast to other models, there exists no simple relationship between the set of transactions initiated and those that are committed. Serializability is guaranteed by permitting only those restructuring commands that preserve a serializable history.

A split divides a running transaction TA into two transactions, TA and TB. Read and write operations that have been executed by T A are assigned to TA or TB. TA and TB are then responsible for committing or aborting the assigned operations. A split is only allowed to be executed if TA and TB are serializable. Dependent on the assignment of conflicting operations we can distinguish between a serial split where the commit of TB is dependent on the commit of TA and an independent split where TB and TA can commit/abort independently. For interactively executed transactions, the serial case is only allowed if T A is committed immediately after the split operation.

The join command joins a transaction T A to the target transaction TB by adding the read and write sets of TA to TB. Before the join becomes valid and T A disappears, TB has to accept it. Afterwards, TB can use any resources from TA and all changes of TA to the database will become valid at commit of TB. Uncontrolled joining of two transactions can lead to non-serializable histories, e.g., if TA is serialized before Te, Te is serialized before TB, and TA and TB are joined.

Splitting and joining ongoing transactions enable a cooperative behavior by delegating parts of transactions to a co-worker. Other advantages of the split/join model are adaptive recovery and increased concurrency if the split transaction is committed immediately, i.e., the resources are released and made persistent prior to the commit of the original transaction. An open problem is how to ensure that two transactions resulting from a split form again consistent units of work and how the user can specify resource partitioning.

A similar concept to split/join, i.e., delegation, can be found in ACTA [Chrysanthis and Ramamritham, 1990, Chrysanthis and Ramamritham, 1992]. ACTA is a transaction meta-model that can be used to specify the types of dependencies between transactions. One of its building blocks is the delegation primitive [Chrysanthis and Ramamritham, 1993]. Delegation in ACTA means that the responsibility for committing or aborting actions can be delegated from one transaction to another transaction to broaden the visibility of the delegatee and to tailor the recovery properties of a transaction model. In this way, tentative results can be made visible to co-workers. How delegation in ACTA can be implemented is described in [Martin and Ramamritham, 1997].

3.5.4 Check-out/Check-in, Versioning and Workspaces

One of the simplest form of synchronizing the access of a team of designers to a shared repository is the check-out/check-in model. Data objects have to be explicitly checked-out by a designer, i.e., objects are copied from the shared database to his private workspace where the objects can be manipulated. In


the simplest approach, checked-out objects are reserved for exclusive access until a later check-in into the shared database. Check-out and check-in have to be atomic. Obviously, this policy limits the availability of data enormously.

Therefore, the check-outfcheck-in model appears in most cases in tandem with versions and configurations [Katz, 1990] like in version control tools [Tichy, 1985]. A version of an object is simply a "snapshot" of an object's state at a particular point in time. Versions may be mutable or immutable. If an immutable version is checked-out, a new successor version is first derived from the original one and then copied to the workspace. The checked-out version is reserved exclusively but another user may derive a new version that can be checked out. This results in branches in the version history of an object. Of course, the parallel versions have to be merged (manually) in order to come up with a single, commonly agreed result of the object.

Another problem is to keep track of which versions of different objects form a consistent version set. For example, if there exists several versions of objects X and Y it is difficult to find out which versions of X and Y can be used to compile executable code. Therefore, versions are grouped into consistent versions sets, called configurations. Dealing with configurations complicates version management and check-outfcheck-in and might decrease concurrency because always whole configurations have to be reserved.

Check-out models together with versioning and configurations supports the exchange of results among co-workers accepting that versions have to merged later and that version sets may become inconsistent.

For the purpose of software development, several extensions of the checkout model have been developed, which take advantage of the opportunity of software consistency checking in those environments [Kaiser and Feiler, 1987, Kaiser et al., 1989, Honda, 1988]. The Network Software Environment [Honda, 1988] supports an optimistic coordination scheme by forcing users to merge concurrently created versions of source code (copy f modify f merge cycle). Smile [Kaiser and Feiler, 1987] provides one shared repository for the public configuration and a private workspaces with a private configuration for each user. If a private configuration is checked-in, the system recompiles the modified source files and tries to link them together with the unmodified modules in the shared repository. If this fails, the check-in operation is aborted. Infuse [Kaiser et al., 1989] generalizes this approach by supporting additionally semi-public workspaces and by using execution-time consistency checking. Due to the fact that such consistency checking mechanism are not applicable in all application domains, these approaches are not a general solution.

3.5.5 Group Transactions

CAD transactions [Bancilhon et al., 1985] enhance the basic check-out model by introducing a hierarchy of a public repository, several semi-public databases (one per design project transaction), and private databases for active designer's transactions.


Similar to [Bancilhon et al., 1985], group-oriented transaction approaches describe the overall working process as a transaction hierarchy consisting of group transactions. Individual user transactions form the leaves of the transaction hierarchy. Visibility between transactions is supported by extended locking schemes [Klahold et al., 1985, Fernandez and Zdonik, 1989, Elmagarmid et al., 1992] or by following predefined access patterns that define the applicationspecific correctness criteria like in [Nodine and Zdonik, 1990, Nodine et al., 1992].

In the cooperative transaction hierarchy approach [Nodine and Zdonik, 1990, Nodine et al., 1992] each group transaction defines a set of rules that specify the way the child transactions can interact and how data objects can be shared among them. Correct histories are specified by patterns and conflicts [Skarra, 1989] using finite-state automata. Conflicts are comparable to locks in the sense that they specify when certain operations can not be executed. Patterns specify that specific operation sequences have to occur. Cooperation is enabled by allowing non-serializable executions of transactions that belong to the same group. The usability of this model is restricted because significant parts of the cooperative application have to be pre-specified in order to describe whether a particular non-serializable execution is correct or not.

3.5.6 Participants Transactions

The participant transaction model [Kaiser, 1995] defines each transaction as a participant in a specified domain. The domain represents the set of user transactions controlled by users collaborating on a common task. Participant transactions in the same domain need not to be (conflict) serializable (only transactions of different domains have to be serializable). Because the participant transaction model is based on read/write actions and no concurrency control applies to a domain, this can lead to inconsistencies of data accessed in a domain (e.g., updates based on data no longer valid) and counter-intuitive behavior of the system from the user's viewpoint.

3.5.7 Groupware Systems

Most groupware systems [Ellis et al., 1991] synchronize cooperative access to shared data in a more or less ad hoc manner. Concurrency control in most cooperative hypertext systems is based on mechanisms like explicit user-controlled locking of objects, different lock modes, extended lock semantics, and notifications [Wiil and Leggett, 1993, Greif and Sarin, 1987]. Some systems are using floor passing protocols [Greif and Sarin, 1987] to synchronize concurrent operations on shared data, thereby limiting the availability of data. Other systems do not provide any concurrency control at all and rely on social protocols [Ellis et al., 1991]. Other approaches in the CSCW area (for example, [Ellis and Gibbs, 1989]) are only applicable to real-time groupware systems like shared whiteboards and synchronous group editors. Most of these systems are based on replication of data and use multicast protocols (such as [Birman et al., 1991])


for synchronization purposes. Real-time groupware systems do not address the issues of persistency of data and recovery to ensure fault-tolerant processing.

In [Anfindsen, 1997], there is also a nested transaction model addressing needs of groupware systems.

3.5.8 Transactional workBows

The term transactional workflow was made known to a larger audience in [Attie et al., 1993]. The term is used to emphasize the relevance of transactional properties for workflows. A transactional workflow involves coordinated execution of tasks which may require the access of heterogeneous, autonomous and distributed database systems. The term also implies dependency-based approach to control flow, meaning that the coordination requirements are expressed by control flow dependencies, which specify a precondition for the execution of each task. The preconditions are based on

• the execution state of other tasks (Le., whether they are committed, aborted or ended),

• output parameters of other tasks, or

• on external variables (e.g., on time).

Many ATMs (Advanced Transaction Model) have been proposed for modeling workflows, e.g., nested transactions in [Dayal et al., 1990, Dayal et al., 1991], open nested transactions in [Breitbart et al., 1993, Weikum, 1993], multilevel transactions in [Buchmann et al., 1992], sagas in [Garcia-Molina et al., 1990] and flexible transactions in [Ansari et al., 1992]. The s-transaction model [Veijalainen, 1990, Veijalainen et al., 1992] was originally developed for an international banking environment and addresses many transactional issues pertinent in workflows.

Modeling a workflow as an extended transaction means that the subtransactions correspond to the tasks of the workflow and the execution structure of the extended transaction corresponds to the control flow of the workflow. Hence, the isolation and atomicity properties of the workflow are determined according to the ATM used.

Due to the limited execution structure (control flow) specification capabilities of most ATMs, workflow models based on an ATM have been augmented by control flow specification features. In general, control flow specification can be presented by a small set of dependencies concerning the abortion and commitment of transactions [Klein, 1991]. However, a fundamental problem in modeling workflows by ATMs is that those provide a predefined set of properties, which are not necessary nor meaningful for all workflow applications [Worah and Sheth, 1996]. Motivated by this also frameworks for tailoring appropriate ATMs for workflows are proposed [Georgakopoulos et al., 1993, Klein, 1991, Biliris et al., 1994, Georgakopolous et al., 1994, Georgakopoulos et al., 1996].


If a workflow is not based on an ATM then the workflow designer has to specify appropriate generalized atomicity and isolation properties for workflows. The nature of the specification depends on the recovery and isolation capabilities the workflow management system provides.

The view that a workflow as a whole is a unit of (R/W) atomicity would require that a failure of any task result in the failure of the workflow. However, analogous with ATMs, a workflow may survive certain failures. In addition, some failures may require human intervention (exception handling). For example, during the execution of a long-lasting workflow the underlying database may change, and if the workflows are not designed to cope with such modifications human intervention is required for the recovery. Consequently workflows may require much more comprehensive solutions to recovery than ATMs.

In the context of workflows it is necessary to distinguish semantic failures (also called logical failures) from system failures. A semantic failure occurs when a task cannot reach its objective, e.g. a flight cannot be reserved. If a workflow does not survive a task failure, then the workflow should be rolledback. Whether this is possible, depends on the compensatability of the tasks it has performed. If one of them cannot be compensated, the atomicity applied should be probabilistic or fuzzy (see above Section 3.4.1). Otherwise one can resort to some form of generalized atomicity.

A system failure causes the loss or corruption of main memory. It may occur, e.g., when electric power fails and is transient from the point of view of the workflow. Analogous to how a DBMS uses the log to cope with system failures workflows use workflow log to cope with system failures.

As the tasks may have externalized their updates they cannot be simply rolled back by storing before images [Bernstein et al., 1987]; instead, they have to be undone by executing compensating actions. Compensating actions may also be needed although the workflow was not aborted. This happens if the workflow has alternative paths, and a task in a path fails causing the compensation of the preceding tasks on the path. The compensation of a task may also require a cascading roll-back, i.e., roll-back of the workflows which have accessed the data updated by the task to be compensated. Further, the success of the compensation should be ensured so that generalized atomicity (cf. above) can be guaranteed.

A sufficient criterion for the correctness of workflow isolation is that the execution of workflows is serializable, i.e., in some sense equivalent to a serial execution. However, the R/W serializability requirement of long-lasting activities overly restricts the performance of the system and might also impossible to achieve, if legacy systems are used to implement the tasks.

Generally, workflow isolation and execution atomicity is a tradeoff between

• workflow execution correctness,

• workflow system performance, and

• and the simplicity of workflow specification and management.


By using semantic information it is possible to weaken or the serializability criterion, and yet ensure workflow execution correctness. However, analogous with traditional semantic concurrency control models [Lynch, 1983, GarciaMolina, 1983] the use of semantic information makes the specification as well as the management of the system more complex.

In general, workflow management and transaction management are orthogonal concepts [Worah and Sheth, 1996]. They can be combined in several ways to form workflows with transactional properties. The same workflow can even apply different transaction models in different parts of it and some parts of a workflow might run outside of a control of any transactional mechanism. In some cases more intra-workflow parallelism can be allowed than in other cases. The same holds for inter-workflow parallelism. In some cases it should be restricted, in some other cases not. For atomicity the same holds and the atomicity and isolation can be combined in several ways. This everything is highly dependent on the semantics of workflows.

We make the distinction between four approaches for specifying isolation properties for workflows. We refer to these as: transaction/task approach, transactional task integration, semantic locking, and conflict specification.

Transaction/Task approach. By this approach, we mean the situation where each task is viewed as an ACID transaction. This solution is rather easy to implement as each task executes on a processing entity. However, isolation requirements spanning over one task (e.g., the above examples) cannot be guaranteed.

Transactional task integration. To better match the transactional requirements of applications, some workflow models (e.g., [Tang and Veijalainen, 1995a, Wachter and Reuter, 1992]) allow one or more tasks to form an ACIDtransaction. So using transactional task integration the unit of isolation may vary from a task to the whole workflow.

Semantic locking. By semantic locking we refer to the approaches where some kind of semantic lock is used to prevent dangerous interleavings of different workflows. Isolation constraint is expressed as a predicate, which has to be valid during the execution of the workflows. For example, a lock could be set which ensures that at least one unit of certain product will be in the inventory. This is a much more liberal constraint than locking with R/W locks a part of the inventory database. Generally, using such predicates instead of requiring transactional properties a much higher degree of concurrency can be achieved. The predicate should not, however, be too complicated in terms of computational complexity (cf. above).

Conflict specification. By conflict specification we refer to the isolation approaches (for example, [Weikum et al., 1993, Breitbart et al., 1993]) where a workflow designer specifies the conflict matrix concerning the tasks of the


workflows. The matrix and its use is analogous with the read/write conflict matrix [Bernstein et al., 1987] used with the traditional syntactic concurrency control mechanism. Consequently, the scheduler produces conflict serializable executions. That is, execution of workflows is serializable, if an equivalent serial execution exist with the same ordering of conflicting tasks. As the conflict specification utilizes the semantics of the application, this approach allows more concurrency than the traditional syntactic (read/write) concurrency control model [Bernstein et al., 1987].

A salient feature of workflow concurrency control is that it may support one or more approaches for the specification of workflows isolation requirements. For example, the contract-model [Wachter, 1991, Wachter and Reuter, 1992, Schwenkreis and Reuter, 1996] supports transactional task integration and semantic locking (invariance predicates).

In Chapter 4, we discuss further the general properties of workflows.

3.6 WHAT IS A TRANSACTION MODEL, WHAT IS A TRANSACTIONAL FRAMEWORK?

In the preface of [Elmagarmid, 1992], it states that it is difficult to exactly say what constitutes a transaction model. Are we wiser five years later? It seems so. There are several further developments that help in understanding the scope of transaction modeling. Although atomicity and serializability, as defined with the help of R/W model were revised in many of the transaction models present in the above book, consistency was not challenged (except by epsilon serializability [Pu and Leff, 1991]).

The work on transactional workflows and other CSCW environments, in particular, but also the work on heterogeneous transaction processing has contributed to further understanding of ACID properties. The work in these areas has challenged the consistency assumption. In heterogeneous environments, the local and global transactions do not necessarily have the same view on the data consistency prior to integration. To detect these inconsistencies is a nontrivial task as usually the consistent database states are not explicitly specified, but rather the application semantics is embedded into correctly programmed transaction programs. This is the inherent assumption in traditional transaction processing, as discussed above. Finding out whether a set of global and local transactions has the same view on the global database consistency and resolving possible inconsistencies is certainly beyond the scope of traditional transaction modeling where consistency is assumed as an axiom and the stress is on guaranteeing that executions exhibit atomicity, isolation, and durability. This raises the issue of tools and methods to guarantee consistency, i.e., of a special kind of transactional framework, where the transaction specifications, maybe semi-automatically re-engineered from the programs, could be analyzed.

Second, in CSCW environments and especially in transactional workflow environments it is not evident that the global data consistency always makes sense, at least not between different databases touched by a workflow. But if


there is no data consistency to be guarded, what should be the goal and correctness criteria of transaction processing? The main issue raised by transactional workflows is the very complicated control flow and its management, with many aspects related to generalized atomicity (see Section 3.4.2). It has also been recognized in this context that the entire workflow need not be governed by the same transaction model, but different models might be used in different parts of the same workflow and some parts might even run outside of transactional support. Also, different workflows could apply different transaction models reflecting the fact that they have dissimilar transactional requirements.

The above suggests that transaction models could be customized, as discussed in [Georgakopoulos et al., 1996], in order to meet the workflow application needs. This kind of approach also requires a transactional framework, though different from the above framework tailored to heterogeneous transaction processing environments. If transaction models are to be customized, then the framework is essentially a transactional metamodeling environment which supports the means by which transaction models can be customized.

The third issue of relevance here is the ACTA approach [Chrysanthis and Ramamritham, 1994]. It is special formal tool, actually a family of first-order theories with operation histories as models. With it many, if not all, transaction models have been successfully characterized. However, as discussed in [Georgakopoulos et al., 1996], ACTA cannot be reasonably used to represent specifications of transactions for real systems, although it helps in implementing the transactional properties within the system.

What are then a transaction model and transaction framework? Looking at Figure 3.1, transaction is execution of transaction program, as seen by the DBMS. This can be generalized by saying that a transaction is an execution of a transaction specification (given by an executable language) by transactional run-time system. The scope of any transaction model are transactional computations within a corresponding transactional run-time system. A computation is transactional if it manipulates persistent data and if a set of such computations always exhibits generalized atomicity and serializabiIity properties, pertinent to the transaction model in question.

A transactional framework is the software environment which consists of the transactional run-time system and the specification environment.

Essential parts of the transactional environment are the specification language and tools to describe the individual transactions, and the verification tools. The latter are used to verify correctness of the specifications. Also, because many transaction models require conflict specifications between higherlevel operations, there should be means to express them and also to make them operationally usable by the run-time system. The same holds for the compensating operations, which are often required in order to guarantee the backward recovery and thus a generalized atomicity. As was discussed above, the issues relating to them are not very well understood and should be studied further.

4 APPLICATION REQUIREMENTS

4.1 INTRODUCTION

Thomas Tesch

Peter Verkoulen

Aarno Lehtola

Jari Veijalainen

Olli Pihlajamaa

Aija Sladek

The TRANSCOOP project started with an analysis of different cooperative work scenarios and their underlying computer support. The goal was to found the subsequent specification and transaction model development on a sound basis of requirements which reflect the organization of cooperative work processes in practice and which address the shortcomings of existing solutions. The analysis comprised the investigation of organizational processes, a consideration of existing computer support with its advantages and limitations, and the identification of characteristics that the applications have in common. From these common characteristics, requirements for the specification language and the transaction model were deduced.

The application areas that have been studied are Cooperative Document Authoring (CDA, studied by GMD), Design for Manufacturing (DfM, studied by UT) and Business Workflows (studied by VTT). We have chosen these areas as they cover a fairly broad spectrum of cooperative applications (see also Chapter 2). The choice of which application area was to be studied by which partner was based on the specific expertise of each partner.

59




In order to gain coherent results from the parallel analysis efforts, each application analysis had to relate its results to the following categories. In reality, the categories presented here were derived during the application analysis process. They are biased towards the goal of specification language and a transaction model development:

• Process Structure: one important aspect of the analysis was to investigate the structure of the given application scenarios. The goal was to understand whether the processes have a pre-defined structure, whether this structure is similar for all process instances, and how the structure is determined. Furthermore, the analysis focused on structural patterns like hierarchical structure or flat ordered structure.

• Organizational Context: this category covers the organizational context in which the work process takes place and analyzes how organizational rules effect the work process, e.g., security issues, trust of participants within a cooperative process, autonomy of participants etc.

• Data Management: in order to come up with a new cooperative transaction model that addresses the application needs, knowledge about the data involved in cooperation is extremely important. The goal was to investigate in which respect the properties of data and the required visibility of data put restrictions on how the processes are organized.

• Process Control: with process control we refer to who is in control of the process (human vs. computer system) and how far this control can be delegated to a computer system. This category identifies the automation potential and determines which kind of automation is meaningful.

• Execution and Termination Constraints: for each of the investigated processes, we tried to identify execution and termination constraints that are of high importance for a correct execution of the process. Furthermore, we emphasized on whether these constraints could be observed and possibly enforced by a computer system.

The analysis of the different application domains was performed with varying methods. The workflow part addressed beside the investigation of real world business processes also the features of existing workflow management systems. The analysis was performed by interviews and the implementation of test cases with workflow management systems. The results are presented in Section 4.2.

The analysis of DfM studied real cases from industry. In particular, processes of an airplane manufacturer and a company producing X-ray diagnostic systems for medical purposes have been analyzed. The analysis was performed by means of interviews and the study of company internal materials. All details about the DfM analysis are presented in Section 4.3.

The investigation of authoring processes by GMD-IPSI was mainly performed by the evaluation of the cooperative hypermedia authoring tool SEPIA

APPLICATION REQUIREMENTS 61

[Haake and Wilson, 1992] and its underlying cognitive concepts of joint authoring activities. The analysis results are summarized in Section 4.4.

4.2 REQUIREMENTS FROM WORKFLOW

Organization structures affect on the way work is internally carried out in organizations. Static line hierarchy and dynamic team organization can be regarded as the extreme cases. Same operational goals can be met with different organizational structures.

Tight competition has compelled many companies to find more effective ways to conduct their business. One remedy suggested is to model organizational dynamics as business processes and provide a suitable tool support for this. In this context the terms business process re-engineering (BPR) and workflow have been often quoted. Workflow management systems are used to provide computer support for as large part of the business processes as is feasible. Their usage emphasizes the role of processes as central organizational means to organize work.

4.2.1 General Workf1ow Process Characteristics

The basic idea of using workflows is that a certain portion of the repetitive activities of an organization can be arranged as (information handling) processes that capture a complete business process or an essential part thereof. Each instance of a process serving certain purpose is by structure identical or rather similar to another instance. Thus, it is possible to construct a process specification or for those particular process instances.

Typical examples of processes worth of modeling through a process specification are "customer order handling" or "travel bill handling" within an organization which are repeated in a fairly standard fashion over and over again.

Workflow Process Specifications. These process specifications are composed by an organizational instance called workflow designer, who has authority to determine the "standard" form of particular process instances, based on an organizational analysis. The role of this organizational instance is somewhat similar to that of a database administrator [Ullman, 1982]. The latter designs and maintains database schemata, application architecture, etc. for an organization, whereas the former designs and maintains descriptions of the information handling processes for an organization.

Workflow specifications should be computer supported so that they can be designed and manipulated by software tools. Only so the corresponding process instances, called here workflows, can be automatically or semi-automatically compiled into a form eligible for interpreting by the workflow management system. Workflow processes are thus computer supported both at specification and at instance level.

A workflow specification formalizes both the activities and the control flow (Le., the "process logic") between them, as well as the information pertaining to


the process (i.e., data types) and the data flow between steps. Additionally, the specification can contain real-time requirements, role descriptions, and security and authorization information. In addition, it should contain also transactional properties of the workflow. We elaborate the ingredients below.

The control flow in the specification determines in which order the steps are executed and data flow describes how the input and output data of the activities are linked together. The form of cooperation among the agents is determined by the control flow and the work is facilitated by the workflow data (e.g., form).

Workflow Process Instances. Work flows (i.e., process instances) are usually started and used by end-users. A workflow can also be automated to such an extent that it is started automatically, based on, for example, a calendar. Each of them emanates from a workflow specification and behaves as specified in it. Usually, several agents are attached to a particular workflow, each performing a step. It is also possible to attach fully automatic agents (i.e., computer programs) to a workflow, if all the data needed in the activity in question is available in an electronic form and the logic of the activity can be algorithmically described.

Typical of workflows is that their duration is hours, days or even weeks, rather than seconds or minutes. This is inherent in business processes they model, but also the manually performed parts as such are of course much slower than fully automated parts.

Roles. An important concept especially in this context is role. It is not feasible to include concrete persons' identity into the workflow specification, but rather abstract organizational entities, like "clerk" or "manager" (i.e., roles). This is mainly due to the non-availability of a concrete person during certain period (or s/he left the organization entirely), the process instances referring to that particular persons get stuck-which in turn would require frequent changes of the process specifications. Roles are "filled" with a concrete person available when a step to which the role is attached becomes active in a workflow. In this way, flexible deployment of substitutes is possible in organization.

Roles also help in work balancing, as the workflow management system can monitor the work load of the people and fill the role with a person, who is idle or less loaded than the others.

The roles have also authorization description attached to them; a clerk has usually less powers than a manager. The person attached to a role in a workflow must have all the powers required by the role. The distribution of powers in workflow context usually reflects the powers of the line organization.

In the travel bill case an employee in the role of a traveler starts a workflow by filling the form, the electronic attachments, and submitting it to the system. The appropriate clerks and manager(s) then inspect and sign it in the order specified in the workflow specification and enforced by the system. Finally, accountant transfers the funds to the account of the traveler.


Supervision of Workflows. Workflows being computer supported enable many new things, as compared to manual procedures. These include, automatic controlling of the process instances, temporal restrictions, automatic selection of persons performing the activities, alarms in case a workflow does not make progress, and a more general tracking of the workflow state, duration and other quantitative data by computerized means.

Corresponding to these possibilities there are other organizational instances who control the process instances and the functioning of the system, such as workflow administrators. Measured performance and other data can be used to redesign workflows to meet new needs and tune the system and accomplish better performance.

The workflow approach in general and the better control facilities in particular might affect the working environment of employees in a negative way; The Big Brother has better eyes. Taking into account that a workflow management system might be introduced as a vehicle for Business Process Reengineering, its deployment might raise controversies within organization. BPR and the organizational controversies are large field in itself. The reader is urged to consult appropriate literature.

4.2.2 Organizational Requirements for Workflows

Above we have discussed the general idea and common properties of workflows. Here we grasp more closely possible specific needs.

Local and Business-speciflc Needs. Business environment refers to the surrounding reality where an organization operates. The environment implies continuously changing business practices, standards, legislation, official guidelines, cultural habits etc. to which the organization must adapt in order to do business successfully. Therefore, organizational processes must easily adapt to the changes in the business environment.

Concretely, this means that existing workflow specifications must be modified according to the new business needs and also new specifications developed.

Modularity, Reusability and Versioning of Workflows. The above requirement for continuous development leads to versioning of the specifications. As the workflows often are long-living, there can be several versions of the workflow specifications and workflows present simultaneously. The workflow environment must thus support different versions both for specifications and their instances. And in a large organization there might be thousands of both.

If workflows are used in a greater scale, the specification should be both modular and reusable. Otherwise the result will very probably be an unmanageable mess. Modularity is also a key concept in inter-organizational environments, where autonomous organizations can design their own modules (see Section 4.2.2).


Support for Exceptions. In most workflows, there can be exception situations when, for example, work has to be quickly redistributed, or when the workflow reaches an exception deliberately specified to be manually handled. With regards to workflow management systems this means that system administrators must be able to gracefully intervene active process instances and conduct changes into them, such as reassign activities to new actors. Management operations should be executed without reducing the reliability of the overall execution.

Persistency and Tractability of Workflows. When workflow systems become a technology organizations rely on, they must be able to provide information on what has happened so-far in active processes, irrespective of system failures and the like. This requires from workflow management systems capabilities to recover from failures and restore the workflow state.

A related, but still different requirement is the tractability of workflows afterwards. ISO 9000 series of quality standards is a good example of standards influencing to the work processes by requiring, for example, well-documented and later on tractable execution. Legislation may pose requirements such as long term archiving of central documents and facilities to support re-examinations. This also means that workflows have to be specified in such a way that the necessary information is collected within the workflow and stored persistently in the end. Further, the crucial data produced during the process must be archived in a document archive.

Architecturally, the latter requirement leads to separation between the actual workflow management system and a document archiving system, because it is not reasonable to use the former to store possibly tens of years the documents once produced by a workflow.

Time and Performance Aspects. When workflows have become a crucial part of everyday life of organizations, the performance issues of particular workflow specifications and workflow management systems will be of paramount importance. The problems are typically caused by the large number of workflows being active simultaneously, which drives the human agent's waiting times high. Of course, machines can be overloaded by too high a number of automated tasks. Throughput can also remain small because of too few people attached to the workflows.

One aspect of the problem is large-scale workflow environments. To support environments with many workflows, the architecture of the workflow management systems should be scalable. (The client-server architectures of current workflow products do not necessarily scale up, as pointed out by Alonso [Alonso, 1997].) Management of the performance issues actually requires research and subsequent development of new specification tools, as well suitable monitoring and measuring mechanisms to be implemented in workflow management systems.


Inter-organizational Workflows. An aspect of the workflow approach is that a workflow process instance can be used for cooperation and coordination of the work in a decentralized organization or even across the boundaries of different organizations. In this respect such a process "glues" together individuals working in a process at different locations according to the process specification. The peculiarity from the CSCW perspective is that such an instance can bring together people who newer met and will newer meet or have face to face meetings.

Closely related with the border-crossing workflows is the idea that a workflow management system facilitating the workflows can be used to make interoperable computer environments used in different parts of an organization, or in different organizations, for the purpose of workflow-based cooperation [Brodie and Stonebraker, 1995]. This poses rather complicated requirements for the workflow management architecture that must cope with autonomy, heterogeneity, and distribution, i.e. in this case it is a HAD system.

Autonomy is an issue which directly or indirectly causes many of the problems faced when developing and using workflow systems. The reason is that workflows often cross borders of autonomous organizations or relatively autonomous organizational units.

Organizational (0-) autonomy is of interest here, as well as Design (D-), Management (M-), Communication (C-), and Execution (E-)autonomy. Organizational autonomy means that an organization cannot be controlled by another through (some) interactions. A D-autonomous organization is able to determine itself how its computer hardware and software architecture, telecommunication infrastructure etc. is composed. This leads easily to heterogeneity between the technical infrastructures of different organizations and even organizational units. M-autonomy means that on organization can determine itself how the systems are used (policies, security, level of service, etc.). One of the main consequences of M-autonomy is that computers (e.g., servers, but especially clients) and other end systems (e.g., mobile phones and communicators) can be disconnected from the network longer periods of time, thus exhibiting C-autonomous behavior. Another consequence of M-autonomy is E-autonomy, which means that a computer does not need to perform at all measures indicated in a request or can execute the measures at its own pace and in the way best suited for the organization.

As discussed in [Veijalainen et al., 1992] (see also [Veijalainen, 1993]) a solution to the problems incurred by heterogeneity and autonomy is to establish a homogeneous global domain. In the workflow area, this task is performed, for example, by the Workflow Management Coalition (see Chapter 5).

Generally, workflows can span over D-autonomous organizational units. How can the specification work be organized? A solution is to make the specifications modular and let those organizational units design and specify the modules who are responsible for the steps. Interoperability of the different modules must be preserved by suitable technical means. Modularity also promotes reuse in specifications. For a more detailed discussion, see [Puustjiirvi et al., 1997].


Legacy Systems and Legacy Processes. Work processes of an organization often integrate both manual and computer supported activities. Because of this, workflow management systems should interoperate with existing legacy systems, communications facilities, and other systems of the organization in order to flexibly support the overall working process.

One closely related issue on how to make legacy systems inter-operable would be to use workflows and a workflow management system which tie the legacy systems together in a specific workflow context. This kind of migration of existing legacy systems is an important research topic [Brodie and Stonebraker, 1995, Veijalainen, 1990].

The interoperation with existing systems poses requirements on the architecture of the workflow management systems; they must be able to cope with heterogeneity and have means to support interoperation.

4.2.3 Requirements for the Workflow Specification and Monitoring Tools

As stated above, workflows will become a central asset in organizations. Therefore, organizations will be dependable on them. In order to minimize risks and to be able to optimize workflows and workflow management systems, and use them to achieve interoperability, there should exists powerful enough tools. As concerns the basic process modeling capabilities (activities, control flow, data flow), Workflow Management Coalition has defined a language to it [Lawrence, 1997] (see also Chapter 5).

In addition, workflow specification tools should have means to describe heterogeneous data sources and possibly filters or other data transformation means between heterogeneous activities. In order to guarantee reliable functioning of the system, they should support definition of correctness concepts for workflows and should provide tools to verify the workflow specifications with respect to them. These aspects include transactional correctness of process specifications, correct data handling, real-time constraint checks etc.

Another important, but yet less addressed field is the performance analysis of a set of workflows in terms of throughput/response time, and estimation of resource requirements (system, people) to run the workflows with certain throughput/response time to satisfy customer needs. The tools should also help the re-use of already existing process specifications when designing new ones. This requires flexible versioning support for specifications.

There is need for comprehensive performance monitoring with customizable metrics while detecting bottlenecks in the production use of a workflow management system. It is important to be able to use the monitored data as input in the process specification phase or to automatically alter the execution of the processes (e.g., work balancing). In the current systems the loop back from the monitoring to the definition or execution phase rarely even partially exists.


4.2.4 Transactional Requirements

In Chapter 3, we reviewed several transaction models and thoroughly discussed the concepts and existing transaction models, as well as transactional workflows. As concerns workflows they can be perceived as one transaction (cf. program execution) with properties peculiar to a particular transaction model; or they can be perceived to consist of parts which might have different kind of transactional properties, and some parts might even lack most or all of them. The latter alternative is found to be more realistic in [Georgakopoulos et al., 1996], due to the fact that workflow management systems often must be used together with legacy databases and due to the fact that different workflow applications have different transactional needs. We endorse this view.

Data Management Aspects of Work flows. The central focus of the ACID model is data and its correct handling in the presence of concurrent access and crashes (see Chapter 3 for a more detailed treatment). Somewhat similar to ACID transactions, workflow processes use two kind of data, shared and private data. The shared data is output by a workflow and taken as input by another workflow (or some legacy process), private data is used within a single workflow like the private copies of the persistent data by a traditional transaction.

The shared data has similar requirements as conventional data kept in a database. Thus, it must be persistent, as usually process instances run at non-overlapping time periods. Typically it is therefore kept in a (legacy) database and has thus a durability and consistency provided by the corresponding database management system. Also, it must be consistent in terms of application semantics when released by a workflow.

Private data differ from the a private copy manipulated by an ACID transaction in two ways. First, whereas the latter data is volatile, the private data in workflows must be persistent. This is because of the long duration of the workflows and the requirement for resilience against failures. Second, the private data in a workflow can exists as several copies or versions within a single workflow (e.g. a document set is copied to several agents to be processed simultaneously) .

Concurrency Anomalies. Private data is primarily accessible only to the agents involved in the process instance (the actual application data, like a travel bill form) and to the system (control information). Only if this data is persistent the system can track the state of the processes after crashes and maintain the work incorporated into the private data so far. Because there are potentially several agents active at the same in a workflow, private data might be exposed to concurrency anomalies (e.g., the same travel bill form or customer order is processed by two clerks simultaneously). Thus, the system should have suitable means to prevent such anomalies. The anomalies have a close resemblance with problems caused by intra-transactional parallelism in hierarchically structured transactions (see Chapter 3).


Workflow processes might release some shared data to other processes while still active themselves, by committing it locally or simply writing them into a file. This happens, if the data are semantically correct and final, or it is for performance or semantic reasons necessary to release it. In the sense of classical transaction theory, R/W conflict serializability cannot be maintained in this case. This necessitates setting up new correctness concepts for concurrent workflows. It also aggravates the recovery, because simple recovery does not work, but rather compensating actions must be used for backward recovery and re-execution or resubmission for forward recovery.

Although early release of data is often reasonable and unavoidable, there are workflows which should not release certain data they read or produced before they end, otherwise concurrent workflows might produce unwanted or dangerous results (e.g., see the example on loan processing in [Puustjiirvi et aI., 1997]). Thus, the system should offer flexible means to describe the allowed/forbidden inter-workflow concurrency and enforce it correctly.

Should there be consistency constraints between different pieces of private data or versions of the same piece of data which are in use concurrently, these should be described in the workflow specification, if necessary, and enforced by the workflow management system, possibly with the help of agents. The transaction model developed in TRANSCOOP addresses mainly this issue (see Chapter 7).

Consistency. As concerns shared data consistency, workflows should obey consistency of individual (local) databases, where the shared data are stored. In some cases workflows might be used to enforce inter-database consistency constraints. The problems and requirements in this case are many-faceted and quite similar to those found in heterogeneous transaction processing in multidatabases. There is a more thorough discussion on these issues in [Georgakopoulos et aI., 1996, Puustjiirvi et al., 1997].

Atomicity. From users point of view it would be desirable if a workflow would end in a well-specified successful or non-successful end state and the private and shared data would be in a semantically consistent state. This can be guaranteed only if the shared data is kept in databases which allow the workflow to commit the data when it decides so.

Atomicity of workflows is based on traditional atomicity of steps run as local subtransactions. Thus, either a step is reflected into the local database or not.

In essence, atomicity of workflows can be modeled as generalized atomicity, as discussed in Chapter 3, Section 3.4.1. Certain workflow states, containing steps and private data values, are end states, certain other intermediate states. Reaching an end state means generalized atomicity is achieved. Unfortunately, reaching an end state is not always possible if local databases are extremely autonomous [Veijalainen et al., 1992], the reason being that compensating actions or re-execution/resubmission of tasks do never succeed. Therefore, it might be that especially for inter-organizational workflows the designers are forced to


resort to weaker notions of atomicity, like probabilistic or fuzzy atomicity (see Chapter 3, Section 3.4.1), and manual recovery.

Guaranteeing global consistency of the shared data at the end states is not straightforward. The databases with shared data produced by the workflow need not end up in the initial state after backward recovery of the workflow or a part of it, but as long as the combined state is semantically equivalent with "did not happen" , it is acceptable. Also, after forward recovery the same holds, especially, if contingency transactions are involved (cf. airline ticket reservation from two different companies as alternatives). "Semantically equivalent" above is application dependent; see a more thorough discussion on it in Chapter 3, Section 3.4.1.

Transactional Requirements from Three Applications. We analyzed in the TRANSCOOP project three applications (PORTNET, Valmet error reporting system, and 101-service establishment process at Telecom Finland) to find out whether above rather theoretically motivated transactional properties would be relevant.

PORTNET is an EDI-based system to support in logistics of the Finnish harbors. We analyzed especially the ship arrival procedures. An interesting new phenomenon was that the same message, "announcing the arrival time of a ship", can be received several times with different arrival times, as the ship gets closer. Thus, the port gets several ED I-messages related with this. From modeling point of view, the same workflow step "record arrival time" is repeated in the workflow. This raises a problem of how to model several instances of one step specified, especially, as there is no prior knowledge how many instances there will be. This raises also new questions on how to define dependencies in such a case. We presented a solution to this in [Tang and Veijalainen, 1995c].

How to define generalized atomicity is also a problem. When has the workflow reached an end state as the number of steps in it is not known in advance? This can be solved, e.g., by allowing any number of such steps or requiring that the absolutely trustworthy step has been performed.

Second, the announcements on the arrival times can come through different channels and can be contradictory. This raises the question on trustworthiness of the data and the corresponding trustworthiness of the different instances of the step above. The solution is that one should select the most credible step. This is assumed to be launched by the ship captain, who calls and says when the ship will arrive.

The ship captain uses phone to announce the arrival time and he or she will do it also in the future, as one cannot expect that every ship would have EDI-connection to harbors. This shows that the discussion above on how to combine computer-supported and legacy workflow processes is relevant.

Finally, a ship might change its course and go to another harbor, thus forcing the first target harbor to cancel the preparations for the ship visit. This can


be nicely modeled by a step "canceling the visit", i.e., it is a clear indication of the suitability of compensation for these kind of workflows.

Canceling a visit has further ramifications, as the information on the type of the cargo of the ship has been delivered to the authorities. Dangerous cargoes are registered. Thus, if the ship changes course, the measures for a dangerous cargo must be performed an another harbor. This is a special kind of compensating step in the modeling sense. There is no automatic means to facilitate such situations. A suitable transactional mechanism could help here.

In our second case using a 1OI-service the customer can dial long-distance calls without the Telecom prefix (101) and get reduced fares from the operator. From the 1OI-service establishment case we learned that organizational context might be complicated with many participants from the organization itself, like business unit and several regional agencies. Also, tracking the process state in such an organization manually is tedious (call and ask, send fax). This supports the view that the state of workflows should be traceable by automatic means. FUrther, in this environment there are diverse consistency requirements, such as the customer should not be allowed to use the service in the network before the billing functions. Also, the network must be tuned so that different parts of it have the same view on the service the customer has; a customer might namely have several premises, and thus, several entry points to the network, and all entry points should know at the same time of the service. This means that control information of the Telecom network must be in a consistent state with respect to the customer service after the workflow. In the current system this requirement spans a static consistency constraint between databases and files where the control information are kept.

Finally, setting up the service requires sometimes inter-organizational workflows, as the customer is physically connected to the switch of an competitor and the switch must be tuned to forward the 1OI-prefixed calls appropriately. This interaction with other organizations was done during the analysis phase by standardized faxes between the Telecom operators. Additionally, the credibility of the customer is checked from an outside organization, before the service is set up.

Compensation is reasonable concept in these workflows, as the customer might cancel his order, while the service is being set up. Also, the service is set up while the credibility is checked and if the result is negative, the process of setting up the service is stopped and the steps performed rolled-back, as well as the service request denied towards the customer. In the manual phase we analyzed the process was tedious to stop and roll-back as its state was not known centrally. For the same reason, the customer inquiries about the delivery time of the service were difficult to answer.

The versions of the workflow specifications were recognized as important in this environment.

The VAL MET error reporting case used a Lotus Notes implementation between VALMET and a software house (subcontractor) to report errors in the software delivered. The severity of the errors was specified and the subcontrac-


tor was supposed to react accordingly. From this case we learned how interorganizational workflows can be used to guide legally binding actions between organizations. The system recorded, whether the subcontractor had reacted on time and this was also used to assess whether it had kept the contract.

We urge the reader to consult [Juopperi et al., 1995, Tesch and Verkoulen, 1995J for more details on the analyzed applications and commercial workflow products.

4.3 REQUIREMENTS FROM DESIGN FOR MANUFACTURING

The scope of Design for Manufacturing is the engineering design of complex discrete products. Examples of complex products are airplanes and X-ray diagnostic systems for medical purposes. An essential part of DfM is the early involvement of specialists from downstream processes (such as production and manufacturing engineers) in the upstream design process. A downstream process is a process whose execution depends on the outcome of the so-called upstream process. In this section, design is an upstream process and production engineering, production planning and manufacturing are downstream processes. By studying cases from industry, we have traced the characteristics of cooperation in DfM.

Design for Manufacturing integrates as much as possible design, production engineering, and manufacturing, and, hence, corresponds to a cooperative activity of designers, production engineers, and manufacturing experts. This implies that the support of information systems has to be integrated too. Such an integrated information system is going to be used cooperatively by designers, production engineers and manufacturers. This imposes certain requirements on the system.

The information systems needed within the field of DfM, are still in the developing phase, due to the complexity of the problems found in DfM. Not only does DfM require the manipulation of complex data structures, but it also requires sophisticated mechanisms of cooperative interactions to support the product development process. These are needed because the product development process found in DfM, tries to combine the creative efforts of experts from different fields. Within DfM, cooperation is found in different levels of the product development project. It is found on the level of project management where people from different departments within a company have to work together, but it is also found between designers that closely work together in the detail design of a certain part.

Traditionally, the different specialists from design, production engineering, production planning and manufacturing work in a so-called "over the wall" approach. The order in which activities need to be executed and the persons responsible are clearly defined.

When specialists of a certain department finish their job, they "throw" their plan or product over the wall to the next department, which then can do their part of the job based on this plan or product. Usually it appears that a


subsequent department finds some shortcomings or impossibilities that result in a throwback of the plan or product to one of the previous departments. Consequently, a new product or plan needs to be produced, increasing the number of product development cycles. In the end, after going through a number of cycles, a completed product is delivered.

Bad design choices made in the design stage, may lead to a lot of effort (and thus costs) in the later stages to achieve the desired quality. A solution to improve the quality of design choices is to increase cooperation by an early involvement of specialists from later stages.

The main characteristic of DfM as opposed to the design phase in the traditional process, is the concept of early involvement. By involving production engineers, production planners and manufacturers in the design process, this stage may take more time. Because problems in the design are detected earlier, fewer design cycles are necessary and therefore total development time is decreased, though.

As a result of the early involvement, some of the activities within DfM can, and usually will be executed concurrently. Letting people work concurrently implies that coordination and control are required. This means that frequent exchange of (mostly small batches of) information is necessary, but it also means that its members need to work in a systematic way.

In the remainder of this section, we will sketch the main characteristics of the information systems that are (to be) used for supporting DfM.

The product model is at the center of the information that is needed for designing an artifact. During the concept design, the product model will often be represented as a single set of related data (often called product constraints) which represent the solutions that have to be taken to make a product that meets the initial requirements.

During detailed design and product engineering, it is not always possible to maintain a unified product model, and sometimes it is not even desirable. For example in aircraft design we see that the experts from different disciplines use their own models for the representation of a wing. In [Bond and Ricci, 1992], it is stated that the experts of the different disciplines do not even completely comprehend the models used in other disciplines.

When it is not possible to use a unified product model, a complex product model will be used that consists of a skeleton to which all the multiple product views are attached. Because an artifact often consists of many parts that themselves consist of parts again, the skeleton is likely to have a hierarchical structure. Within the field of discrete engineering the skeleton is commonly found in the Bill of Materials.

We assume that all information in the complex product model is grouped in logical documents. The concept of logical documents is an extension of the usual concept of a document, such that a certain logical document could also represent a certain view of the product. We assume that the multiple product views are represented in different logical documents. In the remaining of the report we just use the word 'document' when a 'logical document' is meant.


The documents used during a design project can be divided into documents that contain the information of the product model and into those that contain information about the design process. The first kind of documents will be called the primary documents; the other ones will be called secondary documents. These contain information necessary for project management and often refer to primary documents.

In the following subsections, the product model and the documents will be described in more detail. Although we have tried to discuss all the different aspects of the information system in different sections, some overlap is inevitable, due to the complexity of the information system.

Product Model. We noticed that both unified and complex product models are being used at different stages of the product design. Whether a complex product model will be used depends strongly on the nature of the artifact. In some cases several different (but related) models are used in the different design stages. We assume that the principles that apply to a single product model can also be extended to multiple models.

The Unified Product Model. During the concept design (and possibly also during the detail design of a certain component of the product), a unified product model is used to represent the artifact (or part ofit). The unified product model is often stored in a single document, for example as a 3-dimensional drawing or as a (product) constraint database. Because of the dynamic way in which the unified product model is manipulated by one or more engineers, there is usually no versioning available. It may happen that several variants, representing different solutions, may exist in parallel as long as no final decision has been made about the solution that is chosen.

Product Constraints in the Unified Product Model. There are many ways to categorize product constraints. There are approaches in DfM that consider each datum that defines the product in a certain way, a constraint. We will not follow that nomenclature here. Because we are focused on describing the information model, we will divide the constraints into implicit and explicit constraints.

Implicit product constraints are the constraints that are implied by the modeling techniques that are used to represent the product model. If, for example, solid-modeling (a technique by which the geometrical properties of an artifact are represented by a number of 3-dimensional solids) is used it means that the product is represented by solids. The data representing a certain solid have to meet certain criteria to be correct. It is usually impossible that two solids overlap in space. This restriction leads to all kinds of explicit constraints. The kind of constraints that can be expressed by implicit constraints are a result of the predefined data structures used to represent the data in combination with the explicit database constraints that apply to these data. The checking of the implicit constraints is often done automatically by the tools that are used


to manipulate the data. An example of the latter is static type checking in a typed specification language.

Explicit product constraints are constraints that have to be expressed explicitly by means of a (logic) specification language. These constraints can be of arbitrary complexity. Explicit constraints are mostly used in the preliminary design stages. In some cases, testing the constraints can be a complicated task, like for example an aerodynamic constraint of a wing. For simpler problems, constraint managers are being used which are able to reason with constraints that are represented in a certain form.

There is another classification of product constraints, orthogonal to the one above, that we would like to mention. The classification is the following. Some constraints simply may never be violated (like "the plane has to be such that it can accommodate at least 70 passengers"). This may seem obvious, but there is another class of constraints: the deontic constraints. For example: "the distance between two passenger seats should be at least x meter". We want deontic constraints to be satisfied, but their violation does not cause disasters to happen. You could also call such constraints non-fatal.

It is also possible that some predefined activities have to be carried out upon notice of the violation of a deontic constraint. For example, when the constraint about the distance between seats is violated, one could decide to diminish the number of seats in the plane or to make it longer. We call these corrective actions.

The Complex Product Model. Once the amount of information becomes too large, the product model is often represented as a skeleton and a set of related documents. The skeleton can be viewed as a set of objects (components) and relationships between them. Because most artifacts have a hierarchical structure, the skeleton product model will reflect this hierarchical structure. In other words, the skeleton consists of a tree that describes how the artifact can be divided into parts, which themselves can be divided into parts, etc.

In some cases this tree is also used as the production model that states how the parts are assembled together. This is, for example, the case with COPICS (Communication-oriented Production Information and Control System) which is actually a logistic system used during production engineering and manufacturing in the 'Philips' case. We observed that this system was also being used during the detailed engineering of their products where it serves as a skeleton for the product model.

In other cases the subdivision is standardized by a coding system that gives a unique code to each of the components. These coding systems have a hierarchical structure were a new coding is extended at each level of subdivision.

We note that in some cases, where a line of products is developed, it is possible that the trees of different products have whole branches in common. In this case it is not correct to talk about trees, but is it better to talk about Directed Acyclic Graphs (DAG).


Explicit Relationships. Besides the top-down relationships between the components and their subcomponents there may also be horizontal relationships between components on the same level. These relationships are often called explicit relationships, because they are not implied by the hierarchical structure. The explicit relationships can be between sibling components (e.g., components that are part of the same (super)component) or between components in completely different branches. It is even possible that there are relationships that are not strictly horizontal, but cross the levels in the hierarchy. An example of this is the relationship between the packing material (used only for shipment) and a certain small part of the artifact, that has to be assembled (installed) on site. The packing material is usual on a high level, while the part could be at a very low level.

Versioning of the Skeleton. If for some reason the skeleton of a complex product model has to be changed, an explicit version mechanism might be needed. The COPICS system, which was used in the 'Philips' case has a limited versioning system per component in the hierarchical product model.

Product Constraints in the Complex Product Model. Once the product model is represented by objects and links, the product constraints are likewise divided. There are constraints that apply to a single component (we call these intra-component constraints) and there are constraints between components (we call these inter-component constraints). This division, however, is not obvious, because an intra-component constraint on a certain component can be an inter-component constraint between two of its subcomponents. The inter-component constraints can be divided into those that appear between siblings (components that have a common super-component) and those that are associated between explicit relationships. Often the explicit relations are identified because of existing inter-component constraints.

It might be clear that the representation and the management of constraints in the complex product model is not a trivial problem.

Primary Documents. As we saw in the previous section, the complex product model consists of a skeleton and documents containing specific information of the product model. This information includes the product constraints as well. We will use the concept of a document in a much broader sense than only documents that are printed on paper. We would rather define it as a collection of information that is represented and modified as a whole. Examples of documents are: bills of material, solid models, any kind of tables but also sets of explicit product constraints.

Each primary document can be associated with a component (or an explicit relationship when it specifies the interface between two components). Each component can have several documents associated with it, which contain information about different aspects of that component. For example, a piece of computer hardware could have a document describing its form, a diagram


explaining the purpose of its connectors and a formal specification of its functionality. Documents themselves can make references to (sub)components.

Versioning of the Documents. Especially in the detailed engineering stage of the design process, there is a need for versioning of documents. If more than one version of a document is kept in the information system, versions can be divided into: current, historical and being-updated versions (working copies). Several versioning mechanisms are possible. Most versioning mechanisms allow only a single version to be the current version. In situations where cooperation support is needed, it might be possible that more than one working copy of a document exists. Not all systems keep historical documents on-line available.

Especially during concept design, different alternative solutions are studied in parallel. For this reason parallel versions of a document may be needed.

Special attention should be paid to the versioning of documents where the contents is built (retrieved automatically) from the contents of other documents. The version of such documents should depend (by some method) on the versions of their source documents.

Constraints Between Documents. In a certain way the same things that apply to a unified product model, regarding constraints, also apply to documents that represent a certain view of the product or deal with a certain component in the product.

As we saw, the constraints can be divided into intra- and inter-component constraints. Analogously, we can also make a distinction between intra- and inter-document constraints. From the assumption that all information (including constraints) is kept in documents, it means that all inter-document constraints have to be kept in documents as well.

Inter-document constraints lead to inter-document dependencies. This is especially important with respect to the versioning of documents. Inter-document dependencies are related to the methods in which new versions of documents are made current. It seems to be logical that versions of documents can only be made current if the documents are correct with respect to the constraints. This is important in the context of views: sometimes, (part of) a document will be a view on another document. Consistent versioning is a prerequisite to keep information consistent in such situations. To guarantee this, explicit database constraints could be used to represent the dependencies between the documents.

Views. Within the complex product model, different views on the product may exist. These different views are usually represented in different documents. In some cases these product views are derived from each other. For example, 2-dimensional drawings could be extracted from a 3-dimensional model. This causes a document to be a 'database' view of another document, resulting in an explicit relationship between the documents.


Secondary Documents. All the documents that contain information that is not directly concerned with the product model or the production process, are considered to be secondary documents.

The secondary documents contain a whole range of documents, from official reports used in project management to private e-mail messages exchanged between two engineers. They can be divided into documents that have to be stored permanently in the information system and documents that are nonpersistent. Important aspects of the project management such as workflow, task division and planning will be recorded and be communicated in secondary documents.

In some cases it is difficult to determine whether a document is primary or secondary. For example the results of a complex calculation can be considered as secondary information when it is purely derived information or as primary information if it represents an essential property of the product module.

4.3.1 Operations in the Information Model

It will be clear from the previous sections that the information systems that should support DfM, are complex. To summarize all possible operations in such information systems will likely be impossible. As these information systems are used by teams of engineers, a high degree of concurrency in the operations performed on the information system, is very likely. Clearly, there is a need for supporting cooperation between the users of the information system.

The operations can be divided into operations related to project management (including all communication between team members) and operations on

the product model. But before we describe these operations, we first discuss scenarios on different scales of the project development process.

Scenarios. Within a product development process many tasks can be identified that have to be performed to achieve the desired result.

Not all the tasks are of the same level of management (scale of interest). It is possible to identify several levels of management (or scales of operation) with in a development process.

How a certain task has to be performed can be described by a scenario. This means that scenarios are found on different levels of management within the product development process.

In this sense, a whole product development project or a stage of the project, can be considered as a single task. Nevertheless, it is not very useful to look at scenarios at this scale.

At the scale of documents, scenarios to create and modify documents are often implemented through a versioning mechanism. The process of making one or more documents actual, is considered as the execution of a single scenario instance. Because documents depend on each other and on the product model skeleton, these scenarios can be complicated and can have a clear cooperative element when negotiation is required.


On an even lower scale we find scenario instances within documents. These are needed when documents are modified by different users. A document, for example, may consist of a traditional database that contains specific information or it may consist of a complex drawing with multiple views that are manipulated independently. Traditional database transactions can be considered as a limited form of scenario instances. It often happens that a drawing is used as a reference drawing for another drawing. It may happen that two users who work on different aspects of the same component, want to see each others drawings concurrently. In all these cases (cooperative) transaction mechanisms are required

Project Management. Project management is important for the success of the project. Because the operations on the product model are all directly or indirectly controlled by project management, we will describe the different activities of project management first. We remark that certain project management activities depend strongly on the information stored in the product model.

A primary function of project management is the allocation and effective application of resources. Human resources form the most important resource for the product development process. Project management will focus on the formation of project teams and the organization of the activities in the project team. For large projects it is possible that several independent (sub)teams are used, which all take care of their own project management.

In the following paragraphs, we will focus on a number of specific functions and activities that are part of project management.

Project Lead Function. The project lead function is responsible for the progress (and quality) of the product development process. For this reason it needs information about the status of the process; it should take the appropriate measures if needed. Important points in the product development process are the transition points between the different stages. The process lead function is also responsible for settling the matter in case of unresolved conflicts.

Reviewing and Sign-off Activities. The purpose of a review is a quality check of the proposed plans/designs. Therefore an evaluation of design decisions takes place by experts and other responsible people.

A review may be formal or informal. A formal review is planned by project control at formal stage transitions of the product development process. The state of the plans/designs is frozen while being examined. The outcome is prescriptive for the further progress of the product development process. The intention is not to backtrack to design decisions made before the formal review.

Informal reviews are meant to increase the quality and to decrease the uncertainty of design decisions during design activities. Here plans/designs are signed off by the participating reviewers. For every different design, a different


group of reviewers may exist or even be formed dynamically. After a sign-off, a design or plan can be released.

Task Identification. At the beginning of each stage of the product development process, tasks have to be identified that have to be performed to ensure a successful completion of the stage. Also in the middle of a stage it can be necessary to rearrange tasks or to subdivide tasks into subtasks. Task identification relies on information stored in the product model.

Task Assignment. Once tasks have been identified they have to be assigned to team members. In some cases new team members have to be involved in the project. The identification of tasks will often be recorded in secondary documents. Formal tool support may be necessary. Most tasks will involve the creation of (new versions of) documents.

Planning. Closely related to task identification and assignment are planning activities. The complexity of planning activities is influenced by the complexity of the product model, the number of activities and the dependencies between the activities.

Workflow Management. Especially when a product development project has a large team, workflow management becomes necessary, especially when the team members are distributed geographically or make use of distributed systems for the storage of the documents. Workflow management involves all the activities that are needed for the distribution of (primary) documents between team members and the notification of team members (often through secondary documents, like schedules and review reports). Workflow management is dealt with extensively in other parts of this book.

Authorization. Authorization is closely related to task assignment and planning. Whether authorization is needed depends on the size of the project. Authorization includes all activities that determine who can see and/or change what information. This should also include the abilities of managing tasks and the abilities of assigning authorization to other team members. Authorization can also be used to prevent the loss of information.

Negotiation. An activity that deserves special attention is the process of negotiation. Negotiation takes place on different levels of the product development process. Some forms of negotiation are clearly on the level of project management, others, however, can also be seen as part of the product model management. For some forms of negotiation it is not clear on which level they belong, or they shift from one level to another.

Negotiations at the level of project management will usually be performed using formal negotiation procedures. Formalized forms of negotiation will be needed when experts from different disciplines have to work together. All team


members will contribute to the product development process with their own expertise, concerns and constraints. A common problem is that experts do not have the same mental model of the design and that experts do not speak the same "language".

Negotiating is often a lengthy and iterative process. The process starts with a set of multiple conflicting goals or assertions. Whenever a proposal has been made, all participants in the negotiation process must give feedback to each other about which parts of the proposal they agree or disagree on. In order to arrive at an agreement, suitable modifications must be proposed. It is necessary to predict and to evaluate whether a proposal is narrowing the differences. Justifications and arguments for modifying proposals must be generated, communicated and recorded.

Recording Design History. Because each design process involves a large number of deliberate and unconscious decisions, it is important to record design decisions. In our division between primary and secondary documents, the design history is part of the secondary documents. For practical reasons it will often be recorded as part of the version management of the primary documents.

4.4 REQUIREMENTS FROM COOPERATIVE DOCUMENT AUTHORING

In the following, we describe the cooperative authoring process considering the specific characteristics of hypermedia documents. We have investigated the cooperative hypermedia authoring tool SEPIA [Haake and Wilson, 1992] and its underlying cognitive model of cooperative authoring activities.

The purpose of the investigation is the identification of requirements for the TransCoop system and, therefore, we treat the authoring process from a database point of view. We assume a scenario in which multiple authors are manipulating a collection of shared documents that are stored in a database management system.

We shortly outline the specific structure of hypermedia documents in contrast to traditional documents. Afterwards we focus on the authoring process emphasizing coordination and cooperation aspects. Despite of the differences between hypermedia documents and traditional documents, most of the identified requirements can be transferred to cooperative authoring processes on traditional documents.

4.4.1 Hypermedia Documents

Hyperdocuments form a new class of (electronic) documents, that is based on the concept of hypertext [Nelson, 1981]. A hypertext is a collection of information entities (nodes) containing cross-references (links) which-with the aid of an interactive browser program-allow the reader to navigate easily within the document.


The main difference to traditional (paper) documents is that hyperdocuments are non-linear. The concept of links gives authors the ability to connect information entities, such as text nodes, in an almost arbitrary way. Therefore, a hyperdocument has an associative, network-like structure. An important implication of the hypertext concept is the interactive usage of hypertexts by their readers.

The nodes and links which form a hyperdocument can be stored in an ordinary file system or can be mapped into database objects in a database management system. SEPIA's hyperdocument structure is modeled explicitly by means of VML [Wiisch and Aberer, 1995], the DML of the object-oriented DBMS VODAK. Applications can provide various presentation styles supporting the authoring process or addressing different readerships, respectively.

If the nodes of a hyperdocument do contain (besides text and simple graphics) also multimedia information, such as complex pictures and continuous information (audio, video, animation), the concept of hypertext is generalized to hypermedia. The term hypermedia addresses multimedia extensions of hyperdocuments, whereas the term hypertext is more related to the structural aspects of hyperdocuments.

Several extensions of the basic hypertext model, such as the introduction of composite nodes [Halasz, 1988] and atomic nodes have been proposed. Composite nodes introduce the concept of aggregation into hypertext structures. They contain other links and nodes and are be used to cluster related information entities. Atomic nodes represent single information entities.

4.4.2 The Authoring Process

In the following, we give a deeper understanding of the authoring process of hypermedia documents. We focus on those parts that have significant impact on the design ofthe TRANSCOOP cooperation model model and its specification capabilities.

When describing the cooperative authoring domain we have to contemplate two different aspects. The product aspect comprises certain constraints and requirements posed on the final product "hyperdocument". The process aspect considers the concrete authoring activities, i.e., the production of an high qualityartifact. Note that a product "hyperdocument" is a result from a concrete authoring process. The interaction of both aspects has several implications on the nature of authoring processes.

The process of writing hyperdocuments is regarded in literature as a problem solving process [Hayes and Flowers, 1986] or, more specifically, as a design activity [Thiiring et al., 1990, Hannemann and Thiiring, 1993]. A characteristic of design activities is that the problems to be solved are not clearly defined. This is reflected by a problem definition which is marked by gaps that are to be filled. The understanding of those gaps is a significant part of the problem solving process. Thus, the analysis of the problem itself is often the most important step for the solution [Simon, 1981]. The weak problem definition


imposes further uncertainty on the problem solving process, i.e., the problem solving process usually can not be specified in beforehand.

This can be easily illustrated by considering how documents are designed. At the beginning, there is often only weak knowledge about the final document, e.g., its subject and the target group of readers. A few constraints of the final document may be available, e.g., size limitations, prescribed layouts, or co-authors. All this is understood as a weak problem definition providing several alternatives for the authors how to gain the final document: they could start outlining the structure of the document, brainstorming further ideas, or studying further literature etc.

Despite these observations, it has been tried to identify a generic structure of authoring process. [Hannemann and Thiiring, 1993] decomposes the overall design problem of writing (hyper)documents in three subproblems addressing the planning of the process itself, i.e., development of a basic document structure and a workplan (planning problem), the acquisition of background material (content problem), and the expression of the authors intentions in a way suitable for the aimed readership (rhetorical problem). Beside these subproblems [Streitz et al., 1989] identifies a fourth subproblem for argumentative documents referring to the construction of argumentation chains (argumentation problem). Although this decomposition of the overall problem in more well-defined subproblems reflects a hierarchical structure and eases the problem solving process, it is important to notice that the identified subproblems are highly interdependent.

The identified subproblems of the authoring process are mapped in the SEPIA system into different authoring activities [Haake and Wilson, 1992]. Hence, in accordance to the presented model, a planning activity, a content activity, a rhetorical activity, and an argumentation activity are linked to each SEPIA document.

Within the different authoring activities, authors choose interactively their actions and frequently undo/redo them as they go along, i.e., the exact sequence of actions within an activity cannot be determined in advance like in office procedures with a more or less predefined set of organizational rules. Hence, authoring systems have to take this opportunistic nature of the authoring process into account, i.e., they should not restrict the authors to follow a predefined sequence of actions.

Authoring processes are usually of long duration. One reason for this is their opportunistic nature and the lack of a predefined problem solving strategy. Because for authoring processes no optimal solution can be found [Simon, 1981], authors always have the impression that the current solution could be improved. This embarrasses authors from finishing the process and, hence, authors have to compromise to a product that is "good enough" , often due to deadlines.


4.4.3 The Cooperative Authoring Process

A significant number of documents result from the work of more than one author. Hence, authors should be assisted in designing the document in a cooperative fashion.

A prerequisite for the cooperative authoring process is that the authors agree on common objectives of their authoring process to produce a single commonly accepted hyperdocument. The generation of a commonly agreed document representing the product "hyperdocument" is the result of a process of negotiations and cooperations between the involved authors. Hence, the authoring process performed by multiple authors can be considered as an extension of the problem solving process discussed in the previous section in which an additional subproblem occurs: the coordination problem [Haake, 1995]. It refers to the coordination of authoring activities such that the synergy effect of cooperation can take place. The coordination of group activities strengthens their efficiency by reducing communication and collaboration effort and helps to avoid the occurrence of conflicting and repetitive actions. We already discussed that the nature of design processes like authoring contradicts a fully pre-planned coordination of activities. Hence, we have to accept that the appearance of some conflicts cannot be foreseen and, thus, the need to cooperate can arise spontaneously.

The essence of cooperation is the exchange of information between acting participants. From the above discussion, it follows that cooperative authoring involves both, explicit exchange of information and implicit exchange of information through common accessible documents. It follows that authors need to share partial results of their activities while still in progress. On the other hand, consistency of the shared artifacts has to be preserved. In contrast to traditional database transactions which assign consistent units of work to a single user, a consistent unit of work is composed interactively by several interacting authors. Hence, it is necessary to coordinate the concurrent access to shared artifacts in a cooperative way such that effort is neither lost nor duplicated.

A cooperative transaction model that is well-suited for such an environment has to support long-running, interactively controlled activities, in which resources can be used cooperatively. The emphasis, therefore, is not on preventing access to resources, but rather on the semantically correct exchange of information among cooperating users. At the same time, we are interested in preserving selected transactional properties of activities performed during a cooperative authoring process.

4.4.4 Dimensions of Cooperative Document Authoring

Process Structure. The identification of different authoring activities within the overall authoring process reflects the hierarchical structure of the authoring processes. Due to permissions and responsibilities of authors in an organization and the structure of a specific authoring process, a further decomposition may take place in a concrete scenario. To support the hierarchical organization


of cooperative authoring processes, the decomposition of the overall work into smaller subactivities should be supported by appropriate specification language constructs.

Although the overall effort is decomposed in sub activities considering specific subproblems of the authoring effort, there is no predefined execution structure among the subactivities. The authoring process is characterized by unstructured ad-hoc collaborations, i.e., the need to cooperate arises spontaneously and is not inherent in the outlined process structure.

Organizational Context. The organizational structure plays only a subordinate role in authoring activities. Only in case of very clearly structured text production efforts like preparation of electronic newspapers where the overall process can be arranged in distinct parts [Siillow, 1994], organization modeling is required.

For cooperative authoring activities as described above cooperation is based on trusting each other. To allow better planning of the process the assignment of responsibilities to the participating authors is useful. Furthermore, fine grained access rights based on user roles along the hyperdocument structure would be helpful. Depending on the progress of the activity, responsibilities and access rights should adapt to the authors tasks.

Data Management. The sharing of final, as well as intermediate artifacts, e.g., drafts, among multiple co-authors is a prerequisite for the cooperative authoring process. Isolation of co-workers, as enforced in traditional ACID transaction models applying serializability as correctness criteria, contradicts the need of cooperation while the activities are in progress. The isolation property of a transaction model has to be relaxed in order to be applicable to cooperative authoring processes. Instead of isolation, a cooperative transaction model has to guarantee that no anomalies are- introduced although tentative working results are exchanged among cooperating authors. The model should offer appropriate primitives for the exchange of information between co-authors. These primitives have to ensure that this information exchange is semantically correct. The model should consider the semantics of activities and their actions occurring within a cooperative authoring process to enable a high degree of cooperation among co-workers. Furthermore, it should provide transactional services that support the spontaneous character of cooperation, e.g., primitives to delegate partial results and activities on demand of the authors.

To explore different alternatives of the same problem, different authors should be able to work at the same time on the same parts of the hyperdocuments. To avoid interference from co-workers, the cooperative transaction model should be able to manage alternative versions of objects. On demand of the authors, it should be possible to exchange alternatively derived versions and to combine them into a commonly accepted version.


Control of the Process. As described earlier, the processes like authoring are creative problem solving processes which are highly interactive and cannot be described in advance. Therefore, the process is emerging under the control of the users rather than under the control of the system. The cooperative transaction model serves only to mediate among the users, record their interactions, ensure consistency during cooperation, but does not prescribe the cooperation of humans.

The includes the provision of services that allow to retract decisions taken by the authors. The TRANSCOOP system should support the compensation as well as the restart of authoring activities on demand of the users. It should allow to flexibly undo and redo actions within activities to allow authors to explore several alternatives to solve the problem.

Execution and Termination Constraints. Due to the opportunistic nature of cooperative authoring processes, it is required that a cooperative activity should be able to proceed (and eventually succeed) even if other parts of the cooperative authoring process fail. A failure within an author's activity should not imply the rollback of another author's effort in their joint work. A cooperative transaction model should include appropriate mechanisms to react on different kinds of such exceptional situations.

The specification of execution constraints should be supported to describe the pre-planned parts of the authoring process. This includes assignments of subactivities to co-authors and constraints on the occurrence of particular subactivities and on their execution order within the overall cooperative authoring process as far as possible, e.g., all text nodes should be spell-checked. The TRANSCOOP specification language has to offer appropriate high-level language constructs for these execution constraints.

4.5 CONSOLIDATED REQUIREMENTS

The objective of this section is to summarize the analysis results, to identify differences and commonalities of the investigated processes, and to derive the requirements for the TRANSCOOP system. During the application analysis we tried to focus on the pure properties of the application scenario under investigation rather than on properties induced by the restrictions of existing computer support. We have categorized the application scenarios according to the five different categories which have already been applied in the analysis parts: (1) the structure of the process, (2) the organizational context, (3) data management issues, (4) control of the process, and (5) execution and termination constraints.

Before discussing similarities and differences of the investigated application areas, we shortly summarize the main observations from the analysis.

The cooperative authoring process as described contains a hierarchical activity structure without prescribing any execution order on the activities. An important characteristic of these processes is that the documents to be pro-


duced can be described only vaguely in advance. Authoring activities require a high degree of flexibility in choosing the next actions to end up with the aimed document. Organizational aspects playa rather subordinate role. The focus lies on a spontaneous and frequent exchange of (intermediate) working results. Cooperation is based on sharing and exchanging common artifacts. The authoring process emerges under the control of the users. In case of exceptional situations, flexibility is required in reacting on failures. Furthermore, there are no predefined termination criteria that could be evaluated by a computer system.

The essential part of DfM is the early involvement of specialists from downstream processes in the upstream design process. Thus, the strengthening of the design process by overlapping design phases requires extensive cooperation and coordination facilities. In comparison to cooperative authoring, more detailed knowledge of the engineering processes in different phases, as well as of the sequence of processing is available.

Workflow processes were considered as automated business processes. They emphasize the organizational aspects of business processes, e.g., modularity of specifications and autonomy requirements of organizational units. Workflows may involve both automated/machine-based tasks, where DBMSs or other information systems are involved, and human-based tasks, where human beings are required to intervene and influence the flow of control, and indeed the cooperation. Considering the heterogeneous technological infrastructure of today's enterprises, certain emphasis has to be put on interoperability issues among workflow enactment services and the integration of legacy systems. However, it has also been recognized in the investigated case studies that workflows are difficult to automate completely, i.e., there is a strong need to capture more dynamics in the workflow models allowing run-time flexibility and improved reaction on exceptional situations.

On a very high level of abstraction, all scenarios are characterized by multiple users involved in multiple activities acting towards a common goal or the production of an product or artifact. To make the differences of the investigated cases more clear, we shortly compare and summarize them according to our analysis categories. Commonalities and differences guide the finding of the requirements for the TRANS COOP system.

Process Structure. The process structure for the investigated application domains ranges from the highly structured, pre-planned, and repetitive workflow scenarios to unstructured, ad-hoc, and non-repetitive problem solving activities. In [March and Simon, 1958], processes are divided in two categories: (1) processes coordinated by plan, and (2) processes coordinated by feedback. Coordination based on schedules is named coordination by plan in contrast to coordination by feedback which reacts on given situations. The more stable and predictable the situation, the greater the reliance on coordination by plan. The more variable and unpredictable the situation, the greater the reliance on coordination by feedback.


The investigated workflow cases and the top level structured activities of DfM fall in the first category. Design problem solving processes like cooperative document authoring and parts of DfM fit in the second category.

Organizational Context. The importance of the organizational environment in which the process takes place is very high for the workflow cases. The coordination plan is often derived from or based on the organizational structure. The organizational structure determines the assignment of human resources to tasks by role resolution, security issues like the authorization to perform or monitor certain task, and how exceptional situations are handled. This does also apply for the top-level phases of Design for Manufacturing. The situation is different for design solving processes where cooperation is based on trusting each other. However, the analysis of the authoring process has shown that fine grained access rights based on the authors responsibilities are to some degree useful.

Data Management. The application analysis has shown how applications suffer from the shortcomings of available DBMS transaction concepts. Workflow applications require more flexible notions of atomicity capturing the semantics of the business process. In order to realize cooperation mechanisms based on exchanging and sharing results as needed for the document authoring scenario, serializable transactions turned out to be impracticable.

Cooperative work is characterized by alternating periods of individual and joint work. On the DBMS level, joint work is achieved by sharing and exchanging information among co-workers. The information exchange can be based on different paradigms like passing of data between actors in case of pre-planned coordination or sharing and controlled visibility of data in case of unstructured ad-hoc cooperations.

Process Control. The objective of this category is to identify how the investigated processes can be at best supported by a computer system. Again, we find here differences for the workflow cases and the authoring scenario. Due to their clear structure and organizational context, workflow processes can be much better controlled by a computer system than design solving processes like authoring or partly DfM. These are centered around humans and their decisions which cannot be pre-planned. Giving computer support for those processes should not only aim at transferring them to another medium but adding a new quality for their processing. To achieve this, cooperation mechanisms are required that keep the control at the human side but fit humans out with means for taking and retracting decisions in a flexible way.

Execution and Termination Constraints. For all of the investigated processes we have identified execution constraints that are critical for a successful and correct execution. For workflows these are often implicitly modeled in the description of control- and data-flow dependencies, e.g., for administrative tasks


two signatures might be needed to successfully terminate a workflow. Similar situations occur in the other scenarios, e.g., a document can only be considered as finished when all parts are spell-checked, and there are no dangling references.

With respect to termination, we observe a difference. A computer system is not able to determine the quality of a document and, therefore, cannot decide whether an authoring activity is finished. This is different for the investigated workflow cases. They can be considered as finished when the last step has been executed according to the coordination plan. The system should help humans to observe such constraints and enforce them when possible.

From the analysis of the application areas, we can identify a spectrum with regard to their cooperation features. Whereas cooperative authoring emphasizes the human controlled aspect of unstructured design activities on the one side, the investigated business workflow applications emphasize organizational aspects together with clear rules that can be controlled by a computer system. Design for Manufacturing can be regarded as structured on the top level but within each of the top-level phases the process is comparable to design processes under the control of humans. Directly related to this observation is the fact that organizational processes are repetitive in contrast to authoring processes where each instance is very different. Another important aspect is the difference in the control of the process: design activities are human controlled, i.e., the process emerges under the control of the human whereas organizational processes can be explicitly coordinated and controlled by a workflow management system [Sheth et al., 1996]. The process spectrum is illustrated by Figure 4.1. In essence, processes on the right side of the spectrum emphasize the coordination aspect of cooperation due to their clear structure whereas processes on the left side of the spectrum emphasize the collaboration aspect of cooperation characterized by ad-hoc sharing and exchanging of information. Collaboration is achieved through flexible sharing and exchanging information whereas coordination is achieved through implementing organizational rules. The relevance of these characteristics varies for the three application domains. The solution paths become more fixed and prescribed on the workflow side, allowing the problem-solving process and termination conditions to be more deterministically described.

Based on this analysis and the results presented in [Tesch and Verkoulen, 1995, Verkoulen and Tesch, 1995, Tesch and Wasch, 1995, Verkoulen et al., 1995, Juopperi et al., 1995], we derive the following requirements for the TRANSCOOP system. Some of them are clearly specification-oriented, whereas others refer to executions of cooperative scenarios and, thus, influence the runtime architecture and the transaction model development.

Coordination Facility. In cooperative efforts different users work together. To achieve a common goal, facilities are needed to coordinate each user's efforts.

Unstructured Ad-hoc

Non-repetitive Human-controlled


CDA

Process spectrum Predefined <: > Structured

r---------- Repetitive System-controlled

Figure 4.1 Spectrum of investigated cooperative application scenarios

For all investigated cooperative processes we found a control flow structure that is derived from specific organizational rules implementing the process. For workflow like scenarios, these rules are part of a scenario specification. In case of design problem solving activities, pre-planned coordination is of less importance but may still help to decompose the overall problem in smaller subproblems.

For more rigid forms of cooperative scenarios, coordination is coupled with the need to dynamically assign responsibilities to tasks, possibly based on the progress of the cooperation.

Relaxed Atomicity. The rollback of the whole cooperative work process in the case of failure is generally not acceptable. It is required that a cooperative activity should be able to proceed (and eventually succeed) even if other parts of the cooperative process fail. A failure within one user's activity should not imply the rollback of another user's work in their joint effort.

Therefore, we require application-dependent atomicity constraints-that is, the constraints have to take the specific semantics of the process structure into account. System-initiated transaction aborts caused by scheduling problems, et cetera, should be dealt with on a lower level.

Exchange of Results. The sharing of final, as well as of intermediate artifacts among co-workers is a prerequisite for most cooperative applications. A cooperative system should provide mechanisms to facilitate the exchange of tentative or partial results, while at the same time guaranteeing that no anomalies are introduced by the exchanges.

The system should be designed in a way that the exchange mechanism is adjustable in order to support exchanges on behalf of humans or on behalf of the system. This is to make the system configurable of the whole spectrum of cooperative scenarios.

The specification language has to offer appropriate primitives to define the semantics of correct information exchanges and the transaction manager has to


provide the corresponding run-time support. The enforcement of information exchanges on behalf of the system should be also specifiable. This could be coupled with the coordination facility.

Private and Shared Data. All three application scenarios can be classified as DBMS-based, asynchronous cooperative applications (see Chapter 2 for the classifications of CSCW applications). Asynchronous cooperative applications do not require that all co-workers are simultaneously present. It is possible that they are geographically distributed and only partially connected, due to mobility. To support geographical distribution and mobility, the model should be able to deal with multiple versions of data.

Furthermore, to explore different solutions of the same problem, different co-workers should be able to work at the same time on the same data without interfering each other. To avoid interference from co-workers, the cooperative system should be able to manage alternative versions of objects. Upon a user's request, it should be possible to exchange versions, and to combine them into a commonly accepted version.

Retraction of Decisions. To support the interactive user control of activities, a cooperative transaction model has to provide services that allow to retract decisions taken by the cooperating users, for example by compensation. This allows, for instance, to explore several alternatives to solve a problem.

The specification language has to provide adequate means to describe how certain activities and decisions can be compensated The transaction model has to have a notion of compensation in order to realize proper compensation support.

Execution Constraints. Execution constraints should ensure that each user acts according to some general rules ensuring consistency and coherence of the data. They gain importance in the presence of information exchange mechanisms based on a correctness criterion beyond serializable transactions.

With execution constraints, it should be possible to specify that all chapters of a document are spell-checked etc. In contrast to the coordination facility requirement which captures organizational rules, execution constraints should ensure correctness at the data level.

Correctness. There is a need to ensure consistency for both the work of a single user as well as for the cooperative effort. Traditional transaction models define database consistency in terms of (R/W) serializability which is based on the assumption that each transaction program is correct when executed in isolation. In order to establish cooperation, serializability is obviously not appropriate. The correctness of cooperative processes can be either defined by specifying the allowed interactions in advance or by having a built-in correctness criterion beyond (R/W) serializability allowing users to act cooperatively without affecting each others in an unexpected manner.


Transactional computations are traditionally based on two properties. A transaction manager guarantees (1) a fault tolerant execution with (2) no anomalies due to multi-user execution. While the idea of "no anomalies" leads in traditional environments to isolation of concurrent computations, it points in cooperative environments to the correct exchange of data between concurrent computations.

Gray and Reuter [Gray and Reuter, 1993] divide transaction models in different classes. They suggest a class of transaction models that follows naturally from the simple ACID model (see Chapter 3). Common property of all these models is that they are founded on notions of structural and dynamic dependencies. Thus, all proposed extensions of the basic ACID model differ only by the protocols for deciding if and when certain state transitions can be externalized.

Cooperative transaction models go beyond the description of structural and dynamic dependencies between state machines. They need notions for handing out objects that are not yet committed and that can be requested back later. This differs from the traditional approaches that are based on spheres of control [Davies, 1978] and, thus, assume that dependencies based on shared access are undesired effects. For the cooperative transaction models, the correctness of those shared accesses or cooperations should be defined by taking the application semantics into account.

Of course, additional requirements are imposed on cooperative systems. For example, to support the mutual awareness of co-workers, notification mechanisms are needed. Additional communication facilities like e-mail or audio may be required for direct negotiation between co-workers. Such services received less attention in the TRANSCOOP project, because the focus was on extending the data management provided by transaction models for cooperative applications. Nevertheless, a cooperative transaction processing system satisfying the above requirements can provide an application-independent nucleus on which to build cooperative systems. Further requirements addressing more technical issues can be found in the description of the TRANSCOOP architecture in Chapter 5.

5 THE TRANSCOOP ARCHITECTURE

5.1 INTRODUCTION

5.1.1 Objective

Aarno Lehtola

Rolf A. de By

Henry Tirri

Jurgen Wasch

On the basis of requirements identified from the case analyses described in Chapter 4, in this chapter our objective is to define an architecture of a cooperative transaction processing system. One of the results of the TRANSCOOP project was a "reference architecture", which offers transaction management support for cooperative applications. This general architecture was described in [de By et al., 1995b] as the TRANSCOOP reference architecture. Such an architecture, however, presents a framework for an idealized abstract situation, without posing any specific resource constraints. In the development of a running TRANSCOOP demonstrator system, we have focused on those components that were most intimately related to the notion of a cooperative transaction. The demonstrator we have implemented in the TRANSCOOP project is an instantiation of this abstract architecture. This system is described in detail in Chapter 8.

In the TRANSCOOP reference architecture, an important distinction is made between the "workers-on-the-scene" and the "workers-behind-the-scene". In the first category are the end-users (called actors) for which the TRANSCOOP system offers a context-we use the phrase "scenario" for this context-that allows cooperation and data handling support. The latter category consists of

93




the scenario designers responsible for the proper definition of scenarios, and administrators, who manage the run-time system and solve exceptional situations. The TRANSCOOP system supports both categories of users and therefore has a compile-time subsystem and a run-time subsystem.

Another central natural issue in the design of an architecture is the identification of well-defined architectural components and their generic functionalities. As we discussed in Chapter 4, the system aims at a fairly wide range of cooperation applications. Thus, all functions required by these application categories need to be accommodated. Consequently, the TRANSCOOP reference architecture has to define the appropriate level of genericity of its components, in order to be able to avoid unnecessary duplication of functionality.

In summary, the goal of the TRANSCOOP reference architecture is to define logical components of a software/hardware system that accommodates cooperation (scenarios) between end-users through the use of advanced database transaction techniques. This definition includes the tools for defining these scenarios, like editors, browsers, compilers, interpreters, prototypers, verifiers, validators and the like, but also the actual resulting run-time system produced by using such tools.

5.1.2 Terminology

One starting point for defining what an architecture is can be found in the standardization work in Open Distributed Processing (ODP) [ODP, 1995]. The notions developed in the ODP framework were also applied in the TRANSCOOP architecture work.

The two essential notions of system and subsystem cannot be given a precise definition, as these terms tend to have an overly general meaning in various domains. What is essential from our point of view is that they are entities comprising hardware and software components arranged in such a way that they address a well-understood goal. In the TRANSCOOP context this goal is to enable the consistent sharing of (persistent) information in cooperative environments. The relationship between the subsystems within a system is another crucial element for understanding the functioning of a system.

The architecture of a system can be defined as a set of rules that define the structure of that system and the interrelationships between its subsystems. In setting up such rules for any non-trivial system, one usually has to deal with many details from which it is better to abstract away at the early stages. The use of such abstractions, however, is problematic since they may obscure the actual, precise functions of the system. Below, we will address the functioning of the system also by discussing a typical "walk-through" of the subsystems.

Another central notion in our terminology is the agent, by which we mean any actor that takes part in a cooperation. Agents are fixed entities that are explicitly identified at specification time. Agents can be active or passive, and their degree of activity can change during the cooperation. Active agents will submit requests and commands; more passive agents will provide services and

THE TRANSCOOP ARCHITECTURE 95

wait for such requests and commands. The distinction between passive and active agents is gradual, and may vary over time.

5.1.3 Previous Work

In addition to the effort spent by the TRANSCOOP consortium, the issues of cooperation and data handling have been discussed in several contexts. A number of academic research projects, industrial products and even some standards have addressed these issues also. The most notable earlier approaches to the field are the ConTract model [Reuter, 1989, Wachter and Reuter, 1992, Reuter and Wachter, 1991, Wachter and Reuter, 1990] and the Concord approach [Ritter et al., 1994].

The ConTract model addressed the definition and implementation of a system plus a model for controlling long-lived, complex computations. It did not define another extended transaction model, but rather focused on an advanced mechanism for grouping ordinary transactions into multi-transaction activities.

The Concord approach focused on supporting transactions in cooperative design environments, built on top of an underlying database management system (DBMS) for object and version management. Another, rather influential architectural approach has been GTE's DOMS architecture [Manola et al., 1990, Buchmann et al., 1992]. Its emphasis was on a computational model that combined distributed objects and transaction processing in a generic manner.

In addition to research projects listed above, several ongoing standardization efforts are closely related to the architectural work in TRANSCOOP. The Object Management Group's initiative of CORBA is well-known by now, and its aims have a clear overlap with ours. Open Distributed Processing [ODP, 1995] aims at distributed systems and computations therein, which conform to a set of standards currently under development by ITU and ISO. As opposed to the generic approaches by ODP and OMG, the Workflow Management Coalition has defined its Reference Model [Hollingsworth, 1994], which very likely will have a great impact on the workflow application domain.

Finally, commercial products, such as IBM's FlowMark package, have also contributed to the field. In Section 5.3, we will discuss many of these efforts and their contributions to the field.

5.1.4 Chapter Overview

Section 5.2 provides the definition of the TRANSCOOP reference architecture and can be understood as our approach to the problem of providing the necessary support for systems offering cooperation and transaction facilities. It presents an overview of all subsystems that were planned and discusses the various ways these subsystems contribute to the overall functionality of the system. Section 5.3 continues where we left the discussion on previous work, and compares the approaches mentioned with the TRANSCOOP approach. We conclude the chapter by Section 5.4, where the choices made in the actual implementation of the TRANSCOOP demonstrator system are discussed.


5.2 THE TRANSCOOP REFERENCE ARCHITECTURE

In this section, we will present a reference architecture for cooperative transaction processing systems, namely the TRANSCOOP reference architecture (see [de By et al., 1995b] for a more detailed description). On the one hand, the systems covered by the architecture must support the definition and verification of cooperative scenarios, i.e., the cooperative behavior of applications with respect to transaction management and coordination issues. On the other hand, the systems must be able to instantiate these cooperative scenarios, and supervise the resulting cooperative scenario instances. They have to govern the execution of cooperative scenario instances and to guarantee that their (transactional) behavior is in accordance with their specifications.

The users who interact with the target systems can be classified in the following categories:

Scenario designers, who use the specification tool set to define, verify and simulate cooperative scenarios as well as generate executable scenario objects from these definitions.

Actors, who start, participate in, and manage cooperative scenario instances. Actors may have different privileges with respect to run-time system services.

Administrators, who manage the run-time system (e.g., monitoring, backups) and solve exceptional situations (e.g.,system failures).

Figure 5.1 illustrates the TRANSCOOP reference architecture. At the highest level of abstraction, three subsystems can be identified, namely the TRANSCOOP Specification Environment (TSE), the TRANSCOOP Object Server (TOS), and the TRANSCOOP Runtime Environment (TRE).

The TSE is a tool set that allows scenario designers to build definitions of cooperative scenarios. Besides the necessary tools like editors, it includes tools to validate the resulting specifications, such as simulators, with which designers can test prototypes. Central to the TSE is a high-level specification language, in our case CoCoA, presented in Chapter 6. These specifications are stored into the TOS. Specifications include, among other things, CoCoA specifications, executable cooperative scenarios, information about actors (including their roles), privileges and access rights, and organizational data. Multi-user access enables the concurrent definition (TSE) and execution (TRE) of cooperative scenarios.

The TRE executes the ready-to-run cooperative scenarios. Upon a start request by some agent, the TRE loads the appropriate executable scenario from the TOS, and then controls the execution of the scenario. The task of the TRE is to ensure the transactional correctness of the scenario as explicitly specified or implied by the scenario definition and to coordinate the scenario execution.

There is no direct connection between the TSE and the TRE. The TRE and the TSE communicate only by retrieving information produced within the TSE

ScofllriO dulQfll'


Actors ( • . g. lPpllca~on .nd-uSl,.. 'yotlm tdmlnl.trltors)

fT;';~"-----" "

: Run-time : EnvltOMllnt : (TRE)

/ \

Figure 5.1 The TransCoop Reference Architecture

and stored within the TOS. This design decision decouples the specification and run-time environments of the system. The advantage is that the design and the implementation of the TSE and the TRE can be done quite independently. This architecture is instantiated (for necessary parts) in the demonstrator system of the TRANSCOOP project (see Chapter 8) .

5.2.1 A Walk-through of the Architecture

Let us first give a brief description of how the TRANSCOOP reference architecture functions, by illustrating the process of designing a cooperative scenario. Scenario designers use the facilities provided by the TSE to define cooperative scenarios in the CoCoA by using the Specification Editor and the tools (Verification Toolbox and Parser/ Type-checker) attached to it. A CoCoA specification can be compiled into a LOTOS/TM specification (LTM) by the CoCoA2LTM compiler which is used to simulate the scenario, using the Simulation Environment .

An executable scenario is derived from two compilations:

1. The CoCoA2CTMSpec compilation maps the transactions involved in a scenario to a format that is understood by the TransCoop Transaction Management Support System (TTMSS) . This code serves to define the transactional behavior of a cooperative scenario execution.

2. the CoCoA2CMSpec compilation generates code for the Cooperation Manager in the TTMSS.


Both the CoCoA2CTMSpec and the CoCoA2CMSpec code will be stored into the TOS as an executable scenario.

The Managing Tool (MT) attached to the User Agent (UA) is used to query and instantiate executable scenarios stored in the TOS. When an executable scenario is instantiated, it is retrieved by the TTMSS which starts the execution. The Managing Tool is also used for controlling the scenario instances and for getting information about them.

Activity instances belonging to a running cooperative scenario instance execute external programs that are used to do the actual work. External programs are started by opening a program connection to the Program Agent (PA) which in turn starts the external program as defined in the scenario definition. After the external program has started, it may call TTMSS functions to;

1. access data from the Database System (DES) using the Object Storage Server (aSS) that adapts the functionality of the underlying database system to the TRANSCOOP Common Object Model, and to

2. communicate with other agents when the participants cooperate.

An activity instance can also initiate a new executable scenario which in turn can include activities that instantiate executable scenarios. Some of these executable sub scenarios can reside on another site which means that inter-TRE communication is needed. The Remote Execution Agent (REA) is used for this kind of communication.

5.2.2 The TransCoop Specification Environment

The first component of the TSE that needs to be described is the graphical User Interface. Its interaction with the user, or with any other TSE component has not been illustrated in Figure 5.1. It integrates the various other components, and its full-fledged version should provide also for methodological support for using the TSE.

The main component for specification is the Specification Editor. It serves as the home base for the designer, as it is the one tool that allows the user to correct specifications and then make it available to other tools for further treatment. Hence, the name is a bit of a misnomer since we do not want to preclude some more intelligence of this tool. From a methodological perspective, we would like to stress that this editor should in fact be capable of supporting edits to the formal text of the specification, but also to the informal and supporting clarifications that should come with it.

One might question the isolation of the Parser/Type-checker component in the architecture. The reason for this is that it seems to have become quite common to support more interactive ways of specification checking, and we feel that the isolation of the Parser/Type-checker serves this purpose well. It is in fact the tool most often used for correctness checks, and it typically may identify the majority of specification errors. Thus, it seems useful to already contemplate using it, for instance, in a duplicate-window mode, where the


Parser/Type-checker runs in one window, and the Specification Editor in another. If the two are tightly coupled-the Specification Editor more as client, the Parser/Type-checker more as server-it might drastically improve user efficiency.

The Compiler Set consists of three compilers or mappers for different purposes. The CoCoA2LTM compiler is primarily there to map onto interpretable code that can be run in simulation mode. Its use probably does not stop here: it is more than likely that some of the tools in the Verification Toolbox actually "understand" LOTOS/TM far better than they do CoCoA, and thus the Specification Editor might have to rely on this compiler/mapper.

The CoCoA2CTMSpec compiler is one of the two basic run-time compilers that bridge the world of specification phase and cooperation run-time. This compiler maps the transactional view involved in a scenario to a format that is understood by the Cooperative Transaction Manager in the TTMSS. The other module of the run-time compilers is the CoCoA2CMSpec compiler. The code it generates from the organizational view of the scenario serves to guard the cooperation scenario for misbehavior, and as such it augments the scenario script by abstracting away from the database functionality and focusing on the event structures used for triggering, polling, negotiation and other cooperation supporting events. This code is interpreted by the Cooperation Manager in the TTMSS.

One of the important components of the TSE is the Simulation Environment. As the name indicates, it allows designers to generate toy versions of the cooperation scenario network of agents, including the database. In TRANSCOOP we contemplate that this simulator is built on the basis of more or less existing stand-alone simulators for LOTOS and for TM. One of the main issues of this component is the proper and seamless integration of the two. With TRANSCOOP providing such new technology, we feel it is of utmost importance that the Simulation Environment actually also simulates the behavior of the transaction model in a correct way. One reason is that we expect the CoCoA language to support (some of) the transaction model primitives directly; another reason is that, by doing so, we also obtain an interesting way of studying the transaction model itself.

The last, but not the least, component should provide the added value of our approach. The Verification Toolbox will include any additional generic tools that will be useful in analyzing the cooperative scenarios. A full study of what tools might be useful in this area has still to be carried out, but it is a priori clear that there is quite some need for such tools: the design of distributed, but highly interactive protocols with a high level of data sharing is quite a difficult task in general.

5.2.3 The TransCoop Object Server (TOS)

The TRANSCOOP Objects Server (TOS) bridges the worlds of specification phase and run-time, and thus provides storage for all persistent data related to


the specification of cooperative scenarios. The TSE stores and retrieves, and the TRE retrieves scenarios and related information. Such persistent information includes scenario definitions, executable scenarios, end-user data (organizations, roles, groups, individuals etc. with authentication and authorization information), and possible system configuration data. The TOS provides standard database functionality and should support versioning of the stored specification objects.

5.2.4 The TransCoop Run-time Environment

The TRANS COOP run-time environment consists of three different types of entities: TRANSCOOP Agents, TRANSCOOP Transaction Management Support System (TTMSS), and TRANSCOOP Object Storage Server (OSS).

The core functionality of the TRE is provided by the TTMSS. The TTMSS supervises many scenario instances of possibly different types concurrently. The internal structure of the TTMSS depends to a large extent on the cooperative transaction model applied, and will here be schematically described for the COACT model used by the TRANSCOOP consortium (see Chapter 7). We assume the more or less standard database functions, and will add two specific components for dealing with cooperation. We discuss these components below.

The TRE interfaces with several other application-specific entities using its agents and the OSS. These entities can be divided into the following categories (in parenthesis acronym, and number of instances to interface):

• Managing Tools (MT, one or more)

• External Programs (EP, one or more)

• Other TTMSSs (zero or more)

• Database System (DBS, one)

Managing Tools are used to instantiate executable scenarios and to control their execution. In addition to this, they may provide monitoring and administration functionality. Activity instances belonging to the scenario execution may start external programs to do the work (with or without human intervention) and to allow cooperation between the participants of the scenario.

Cooperative scenarios may be enterprise-wide or even span across organizational borders. Hence there is a need for two or more TTMSS modules to communicate and for example allow them to ask remote scenario instantiation. The Database System stores durable data used in cooperative scenario instances. This covers application data and status information for running cooperative scenarios.

The TransCoop Transaction Management Support System (TTMSS). The TTMSS is the central component of the TRANSCOOP Run-time Environment. The main task of the TTMSS is to control the execution of scenarios


that have been specified with the TSE tools. Given a cooperative scenario specification, the TTMSS synchronizes all accesses to the application data used in the scenario instances and controls the interactions of the other TRE components involved in a cooperative scenario instance.

While reading and interpreting a scenario, the TTMSS identifies the participating agents in the scenario. The scenario defines and consequentially assumes that all agents in a cooperation use a common, global data model for cooperation data. This assumption makes it possible to actually study transactional properties in the style of advanced transaction models by focusing on operation semantics: since the TTMSS can obtain the abstract semantics and the code for the operations from the scenario specifications, it may employ knowledge about the semantics of data operations, e.g., commutativity of operations, and thus can behave less rigidly in terms of ACID properties. As a consequence, the cooperative transaction model addresses the operation semantics, and needs to be reconciled with the data model.

The TTMSS needs to be able to supervise many scenarios, i.e., scenario instances of possibly different types have to be handled concurrently. This is another example of a typical database functionality (i.e., multi-user support) that has to be present inside the TTMSS. It is assumed that this inter-scenario concurrency can be based on extending standard database concurrency control techniques. Thus, the TRANSCOOP project focused on dealing with the specific requirements of intra-scenario concurrency: The TTMSS handles the scheduling of the various activities inside of active scenario instances taking into account all dependency constraints stated in the specifications. Moreover, it controls the access to the application data accessed within a cooperative scenario instance. A more detailed discussion on the functions provided and used by the TTMSS is provided in [de By et aI., 1995b].

The Cooperative Transaction Manager (CTM). The Cooperative Transaction Manager (CTM) is the core component of the TTMSS. It provides all the functionality that is needed for controlling cooperative transactions, as specified in the transactional view part of a scenario specification. This includes start, abort, commit, suspension, resumption, and compensation of individual activities in a cooperative scenario. Moreover, it has to maintain information about a running cooperative scenario instance. The Cooperative Transaction Manager utilizes a special storage area (Status-Database) in the underlying DBS to log the state of a running cooperative scenario instance persistently. This allows the recovery from system failures. If the current context of individual activities is logged in the Status-Database, forward recover ability of cooperative scenario instance can be achieved.

The Cooperation Manager (CM). The Cooperation Manager (CM) coordinates the correct progress of a scenario execution and maintains the group awareness among the actors involved in a scenario. Its operational aspects are described in the organizational view part of a scenario specification. Moreover, it offers additional coordination facilities to the agents and their users, which are not


included in the Cooperative Transaction Manager. These include, for example, notification mechanisms for notifying agents of important events occurred in a cooperative scenario instance, negotiation facilities, the resolution of user-actor assignments, and deadline management.

The User Agent (UA). The User Agent (UA) adapts the TTMSS managing services for the selected Managing Tool. The U A provides the TTMSS a homogeneous interface to Managing Tools. The Managing Tool is used by actors who start, participate in, and manage scenario instances they are involved in. It is also used by administrative users having a wider variety of functionality and access rights over scenario instances in their use. Administrative functionality also includes managing users and other resources, as well as monitoring the system.

The Program Agent (PA). The Program Agent (PA) is a program module that provides for the TTMSS a homogeneous interface to an external application program. There are PAs that are specially built for interfacing a particular external program. There are also PAs that have a more generic purpose, e.g., launching of programs on a certain platform. External programs can be interactive or they can be executed without human intervention.

The PA uses and provides many functions to the TTMSS. As an example, we describe a function, that starts a new program instance or lets attach to an already running program instance (e.g., by opening an internet socket). The inputs of the function are the program call, the start mode, and the optional user identity code and related password. The program call includes the path and name of the program to be executed, parameters for the program, and commands for setting up the environment for the program (e.g., environment variables). The start mode is used to specify, e.g., whether the connection will be made to an already running instance or whether a new instance of the program will be started. A user identity code and password are needed in case oflaunching an application on some remote node of the network. In the case of a successful operation, the function returns with success status and a session identifier for the started session.

Any protocol between the PA and external programs depends on the interfaces provided by the external program, the operations needed by the scenarios from the external program, the execution environment, and the desired coupling mode. An example of tightly coupled interfacing in a protocol could be the use of MS Excel from a PA using OLE and a customized application protocol. A loosely coupled interface could invoke Excel to edit one full spreadsheet at a time. If the external program is a Unix legacy system, the same protocol could be based on, e.g., pseudo terminal (pty) or SQL*Net access to its database. The transfer of bulk data could be realized for example via a shared file system or database.


The Remote Execution Agent (REA). The Remote Execution Agent (REA) provides means for executing operations on other systems, which may be owned and controlled by other organizations. The remote systems may either be similar to or differ from the TRANSCOOP System. The REA may also execute requests from other systems, as long as they comply with the inter system protocol interface specified.

Autonomy of the systems is preserved by providing an interface based on an object-oriented common data model. In general, it is not possible to know the degree of autonomy of the remote systems, therefore we presume that they are maximally autonomous. This means we assume that they are design, execution, and communication autonomous with all their ramifications [Veijalainen, 1990, Veijalainen, 1993]. In order to be able to interoperate, the systems must have enough in commonality, i.e., support for a homogeneous global domain [Veijalainen et al., 1992]. To preserve design autonomy they must be enhanced by corresponding components. The REA is the central component in achieving interoperability. In the homogeneous domain, a common process model is needed, and both the REA and the TTMSS must comply with it. An individual process model defines the messages, related data, and interactions. The CoCoA language is used to describe individual process models.

The REA uses and provides many functions for the TTMSS. For example consider a function that is used to invoke asynchronous operations executed by some remote TRE. A remote operation in the call can be, for instance, an inquiry for executing a scenario on the remote system, an inquiry for information of a remote scenario instance, an inquiry for audit trail information, or an inquiry of a list of remote scenarios that are in execution or executable for the calling client.

Remote Execution Agents of different TTMSSs communicate using a symmetric protocol, which may have different realization. This protocol is actually the highest protocol in a complete protocol stack covering OSI layers one to seven. In certain cases, message presentations within the protocols can be based on EDIFACT which is widely used in inter-organizational business transactions.

The Object Storage Server (OSS). The Object Storage Server (OSS) is an interface component that interconnects the TRANSCOOP Transaction Management Support System with an external persistent object storage system, referred to as Database System in Figure 5.1.

The main purpose of the OSS is to shield the TTMSS from the characteristic features (interface and language) of the underlying DBS. The OSS therefore can be primarily considered as an "interface mapper" between the TTMSS and the DBS which stores the application data. Thus for different DBS different OSS implementations will be used, i.e., different OSS implementations which are tailored to the specific characteristics of the underlying DBS. Nevertheless, all OSS implementations have to provide the same interface functions to the TTMSS.


Another purpose of the ass is to extend the functionality of the DBS if this object storage system does not offer all the functionality required by the TTMSS. Extending the functionality of the DBS is only possible to a certain extent because in many cases the necessary information is not visible at the application interface of the DBS. (For instance, it may not be possible to determine the "lock" point of a transaction in case of two-phase locking.) The ass must offer similar functions to the ones found in any DBS providing multiuser access, and it should also guarantee ACID properties for transactions.

5.3 COMPARISON TO RELATED WORK

This section contains a short survey of the architecture of related transaction processing systems and a comparison with the TRANSCOOP reference architecture. Here we will focus only on the main features of these systems as a full review is clearly outside the scope of this section. More details can be found in [de By et al., 1995b].

Apricots and the ConTract Model. Apricots [Schwenkreis, 1993] is a prototype implementation of the ConTract model [Wachter and Reuter, 1992]. A ConTract consists of a set of predefined actions with ACID properties called steps and an explicitly specified execution plan called a script. The execution of the steps is controlled by the script. The script basically describes the control flow between steps by offering sequential, loop, branched, and some parallel constructors. A set of steps might be grouped into a single transaction. Concurrent access of global data from different steps can be controlled using invariants, i.e., predicates that check constraints. Forward recovery in the ConTract model is provided using a private context database where the state of steps and a ConTract can be checkpointed. Moreover, a ConTract can be suspended, resumed, compensated, and restarted.

The Apricots prototype consists of the following components (see Figure 5.2): The user interface allows the user to start a ConTract and to interact with it. The ConTract manager is responsible for the execution of the script. It has to guarantee the reliable execution of a started ConTract and is responsible for the forward recovery after a crash and for the requests for transactions. The transaction manager runs the protocol to implement the transactional semantics of a ConTract, e.g., by using two-phase-commit protocol. Step servers are user-programmed components and include the code for the steps. Resource managers support functions on data object like a database etc. The communication system guarantees fault-tolerant communication. It must guarantee that a delivered message will not get lost because of a failure which is ensured by persistent message queues in Apricots.

Concord. The Concord approach is introduced in [Ritter et aI., 1994, Mitschang et al., 1996] as an encompassing process model for supporting design processes. The Concord model claims to support the most important

THE TRANSCOOP ARCffiTECTURE 105

User interface ConTract Transaction manager manager

r--

Communication system

Step server Resource manager

Figure 5.2 The Architecture of the Apricots Prototype.

design principles, such as hierarchical decomposition, goal orientation, stepwise improvement, team-orientation and cooperation. Concord tries to realize this by reflecting the different properties of design processes in three abstraction levels. The focus of the highest level (AC level) is on the description and delegation of design tasks and on the controlled cooperation between these design tasks. Therefore the concept of a design activity (DA) is introduced. A design activity is an operational unit realizing a particular design task executed by a single designer. The second level (DC level) considers goal-oriented tool invocation, i.e. , the internal structure of a DA is described. DAs are made out of several atomic design operations (DOP) that have to be executed in some specific order given by the design strategy of their DA. The DOPs serve as operational units for the execution of design tools. The third level (TE level) provides tool processing of design data. A DOP is processed in three steps: first, the input versions are checked out from the database. Second, the data is processed by various tools. Last, the data is made persistent (checked- in) in the underlying database.

The basic assumption of the proposed Concord architecture (see Figure 5.3) is that the design process is performed in a client/server environment. The shared data repository is located at the server whereas the design work itself is carried out at the designer's workstation. The design manager handles the workflow-like organization of a single-user DA and is located on the client site.


Workstation

Design Manager

~

Cooperation

Manager

cooperation! operation

Workstation

Design Manager

AC Level

DAdesc:riptlon, cooperation relationsbips

DC Level

scripts, rules, constraints

.;~ ... stortOO, ....... ft~~· ............................................• tartDO~ ...... ·n~;~·························

t) Client Transaedon

Manager

checkout

checkin

Server Transaction

Manager

Database Management

System

checkln

CUent Transaction Manager

cnecKOU'

Figure 5.3 Architecture for the Concord Model.

TE Level

DOPconleX!

Design Data

Repository

The transaction manager is split into two components: The client transaction managers reside on the workstations and handle the DOP executions. The server transaction manager at the server site controls concurrent access of all designers to the shared data repository and handles thecheck-in/check-out of design data. The cooperation manager (CM) controls the overall design process and is located at the server site. This enables the CM to exploit the global database management system as an information repository.

The Open Publication Environment. The goal of the Open Publication Environment (OPE) [Muth et al., 1992] is to support a multi-user publishing process where individuals or groups play specialist roles, but want to cooperate and use the system concurrently. Publication activities consists of many sub-activities which require the usage of different tools needed to utilize different existing information sources. User operations (or sub-activities) typically

THE TRANS COOP ARCHITECTURE 107

U~r 1 Task Manager

Task Task Task Expert Expert Expert

I 2

Figure 5.4 System Architecture of the Open Publication Environment.

require interaction and are of long duration. Typically, tasks in a publication process will take place at different nodes in the computer network. Therefore, an open architecture consisting of independently developed modules is proposed.

The general architecture of the OPE {see Figure 5.4} is defined by three basic types of components: Assistants, agents, and tools. Assistants support users by providing access to tools. Each user has its own personal assistant. Each assistant consists of a single task manager and several task experts. The task manager coordinates the task experts which performs the specific tasks by calling the appropriate tools. If a user's task needs services from tools which are not directly accessible by his personal assistant, an assistant of another user can be consulted. Users may not want their assistants to be consulted frequently by other assistants. Instead, agents can be created that can access a subset of tools available to the corresponding assistant. Tools constitute the elementary layer in the architecture. Tools are used by assistants and agents to perform user's task like text editing, spell checking, page layout, and information retrieval. Assistant and agents control the execution of operations offered by these tools. A tool can be shared by several agents and assistants.

The concept of open-nested transactions [Weikum and Schek, 1992] is used in the OPE to control concurrency and recovery. Open-nested transactions constitute hierarchies of sub-transactions an different levels of abstractions. They allow the distributed execution of a global transaction and provide means for partial rollback. If a user has to perform a specific task, start a top-level transaction will be started. The transaction consists of user {inter }actions. For each action that can be executed locally, a sub-transaction in the corresponding


task expert is started. Task expert may start sub-transactions in their associated tools. The tools finally call indivisible actions. User actions that can not be performed locally are forwarded as sub-transactions to agents or foreign assistants.

Workflow Management Coalition and FlowMark. Historically, concrete workflow (management) systems have developed from at least two directions, office procedure systems and image management applications [Abbot and Sarin, 1994). In the most advanced (third generation) systems the workflow specification is given separately, and the essential component is the W orkflow Engine which interprets the specifications. Based on this architecture, an industry-driven international organization called Workflow Management Coalition (WfMC), with around 200 participating organizations is currently standardizing the technology.

The standardization work is centered around the Workflow Reference Model (see Figure 5.5) [Hollingsworth, 1994, Workflow Management Coalition, 1995, Lawrence, 1997). Central in the model is the Workflow Enactment Service which provides the run-time server capable to create, manage and execute workflows. The Workflow Enactment Service may consist of one or more Workflow Engines (cf. above) providing the run-time environment.

The Workflow Enactment Service is surrounded by Workflow Application Programming Interface (WAPI) divided to five different interface areas that are partly overlapping. The WAPI provides functionality to the following kinds of workflow components:

1. Process Definition Tools

2. Workflow Client Applications

3. Invoked Applications

4. Administration and Monitoring Tools

5. Other Workflow Enactment Services

The interfaces allow many other tools to be used and the Workflow Engine can also be used through APls making the system to a "glue" between legacy systems, for instance.

One of the key players in the WfMC is IBM. IBM offered its first version of their own workflow management system FlowMark [Leymann and Altenhuber, 1994) in 1994. (We refer to FlowMark version 1.1 in this section.) The FlowMark architecture can be regarded as an instance of the Workflow Management Coalition Reference Model above.

FlowMark is a fully object-oriented distributed workflow management system that operates on local networks, offering cross-platform support for OS/2, AIX, and Windows. The FlowMark system consists of four different types of components (see Figure 5.6): (1) The FlowMarkserver which is the workflow management engine, (2) the 001 ObjectStore object-oriented database

Administration &

Monitoring Tools


Process Definition Tools

Interrace 1

... \\ rf..11 '11 III II III Ill"" II II'

Interface 2

Workflow

Client

Applications

Interface 3

Invoked

Applications

Figure 5.5 The WfMC's Workflow Reference Model

server (OODB-server), (3) build-time clients, and (4) run-time clients which represents the end-user interfaces. The communication layer provides communication protocol transparency for the FlowMark components.

Build-time clients have functionality for defining and maintaining all the information necessary for a workflow scenario (process) to be executable. Moreover, build-time clients allow to administer the workflow system. Build-time clients have their own OODB clients that communicate directly with the aaDB server. Run-time clients offer a graphical user interface for the end users to start process instances and handle work lists. A run-time client basically consists of the process list, the worklist handler, and the run-time work area. Programs bound to a workflow task can be executed at any host that runs a FlowMarkprogram execution process. The FlowMark server acts as the coordinator and synchronizer for work requests. Its process execution component is responsible for the execution of process instances. The distribution of work requests as well as keeping track of them is done by the worklist server. The OODB server is used by the FlowMark server for managing and storing workflow data.

Comparison with the TransCoop architecture. The TRANSCOOP reference architecture addresses a broad spectrum of applications, Le., it supports unstructured design processes like Cooperative Document Authoring, (semi-


------------------------------------------------------------------, BUILD-TIME CLIENT

r:======::--:====~=- COMMUNI-BUILO·TIME CODe CATIONS WORK AREA CLIENT LAYER

AUTHENTICATIONI TCPIIP AUTHORIZATION ARPC

S

ANIMATION

RUN-TIME CLIENT

COMMUNICATIONS LAYER

0008 SEAVER

TCPIIP NetSlOS

FLOWMARK OBJECTS DATABASE

io-o ------------------_. Oata.truetura •• ---

• Procease.

• Uteri

• Program information

'--------

----- --------------------------------------

COMMUNI- RUNTIME SERVER CATIONS LAVER

SERVER

RUN-TIME WORK AREA

COMMUNICATIONS LAYER rdplIP:

[PROGRAM 1 ~ EXECUTION ooce SERVER CLIENT

( PROCESS LIST

( WORK LIST HANDLER

AUTHENTICATION! AUTHORIZATION ~ [ PROCESS 1

EXECUTION

[ WORK LIST 1 SERVER

'-----

1 ~ ------------------ -------------------_. ---_.'

r-~~:*API-~E!-_E~ I .eMD

1 .DLL

~ ----------------------------------------------------------------.:

Figure 5.6 FlowMark Architecture.

)structured design processes like Design for Manufacturing, and workflow-like applications. In contrast to this, the systems discussed above are designed for dedicated application domains: FlowMark is a product for corporate workflow management, Apricots supports long-lived, workflow-like complex computations, Concord addresses structured design processes, and OPE is designed for unstructured design processes.

Among the systems described above only FlowMark supports specification (and verification by animation) of cooperative scenarios by its build-time client whereas the TRANSCOOP reference architecture includes a full-fledged specification environment with a graphical specification editor, a parser/type-checker, a simulation environment, and a verification toolbox.

THE TRANSCOOP ARCHITECTURE III

For the coordinated execution of cooperative scenarios, we designed the TTMSS. It is responsible for the supervision of ongoing scenario instances. Moreover, it provides means for multi-user cooperations within cooperative scenarios by its cooperative transaction model COACT. In Apricots, the ConTract manager is responsible for the coordination of steps. FlowMark uses the central FlowMark server for this purpose. Both Apricots and FlowMark do not implement mechanisms for supporting multi-user cooperation. In Concord, the design managers control the design flow; multi-user cooperation support is offered by the cooperation manager. In OPE, the task managers coordinate the execution of rather unstructured publishing processes by means of the open nested transaction model. It is not clear how OPE supports multi-user cooperation.

Concurrency control and forward/backward recovery is addressed in the TRANSCOOP reference architecture by means of the TTMSS and the underlying DBS that stores application data and the status of running scenario instances. In Apricots, the step servers and the transaction manager are responsible for concurrency control; forward recovery is addressed by the ConTract manager and backward recovery is done by the resource managers. In the Concord approach, concurrency control is realized by the client transaction managers and the server transaction manager; recovery is addressed in a layered fashion by the design managers, client transaction managers, and the server transaction manager. In OPE, the open nested transaction model is used for currency control and recovery. The task managers, task experts and agents, and tools are jointly responsible for that. In FlowMark, only concurrency control and recovery of workflow instance status information is implemented-transactional support for application data is not included in FlowMark.

5.4 IMPLEMENTATION CHOICES AND DISCUSSION

To instantiate the reference architecture, there exists several implementation choices. Some components might be left out if their functionality is not needed in the particular implementation, e.g., TTMSS-TTMSS interoperability. Alternatively some components can be merged, e.g., due to technological reasons, like the tight coupling of the TTMSS, OSS, and DBS in the TRANS Coop demonstrator implementation.

The goal of this section is to relate our TRANSCOOP demonstrator system (which is presented in detail in Chapter 8) to the TRANSCOOP reference architecture and briefly describe our implementation choices. Important for us was that the TRANSCOOP demonstrator system should support at least the backto-back walk-through from specification to implementation of a cooperative scenario.


5.4.1 User categories

Our prototype implementation supports only two categories of users, namely the scenario designers and the actors; the category of administrators is not directly supported by the demonstrator system. We did not implement special management tools for the administration of the demonstrator. Some management facilities were integrated into the extended SEPIA graphical user interface (see Chapter 8, Section 8.3). The remaining management functionality is available via the ordinary DBS language interfaces.

5.4.2 The Demonstrator Specification Environment

The demonstrator specification environment (see Chapter 8, Section 8.4) consists of the graphical scenario editor, a static analysis tool, a dynamic analysis tool, and the compilers to the run-time environment. The verification environment is not implemented as a separate component; its functionality is integrated into the static analysis tool and the dynamic analysis tool.

The static analysis tool contains the parser /type-checker of the TRANSCOOP reference architecture. Moreover, it checks a number of context-sensitive requirements related to the definition and use of CoCoA cooperative scenarios. The static analysis tool also contains the CoCoA2LTM compiler which generates TM code for the simulation of cooperative scenarios. The dynamic analysis tool is used to simulate and visualize the organizational behavior of CoCoA specifications using the TM Abstract Machine. Furthermore, during simulation the dynamic state of the scenario can be queried using the TM language. In analogy to the TRANSCOOP reference architecture, we have implemented two compilers to the run-time environment, one for the generation of CM code and one for the generation of the corresponding CTM specification.

5.4.3 Storage of Specification Objects

Unlike in the reference architecture, there exists no dedicated TOS component in the TRANS Coop demonstrator system. The demonstrator specification envi~ ronment uses its own storage facilities. The graphical scenario editor generates textual representations of the specification which are stored in the file system. These specification objects can be accessed in later stages of development by the static analysis tool described below. The executable specifications (consisting of a specification for the CM and a corresponding specification for the CTM) are stored in the demonstrator run-time environment's DBS (in our case VODAK/ObjectStore). For CM specifications an ObjectStore database schema for compiled CoCoA specifications was developed. For the storage of CTM specifications the data dictionary of VODAK was extended.


5.4.4 The Demonstrator Run-time Environment

The demonstrator run-time environment (see Chapter 8, Section 8.5) is implemented using the object-oriented database system VODAK and its underlying persistent object storage system ObjectStore. VODAK together with the CTM and CM constitute the TTMSS of the reference architecture. The CTM implements the basic functionality of the TRANSCOOP cooperative transaction model COACT, i.e., it controls the transactional view of a CoCoA scenario. The CM makes sure that the work proceeds in line with the organizational constraints of a CoCoA scenario. Both components share a single status database for persistently storing the current state of an ongoing scenario execution. The status database is implemented as an ObjectStore database similar to the specification database and to the enhanced VODAK data dictionary. In our implementation, ObjectStore corresponds to the DBS of the reference architecture. ObjectStore is wrapped by a generic VODAK-ObjectStore interface which provides the OSS functionality of the reference architecture.

We have not implemented the different types of agents, i.e., UA, PA, REA, in our demonstrator system. The REA was not needed because we only want to build a proof of concepts demonstrator and TTMSS-TTMSS interoperability was not a major issue in the project. With respect to the PA and the U A we took a slightly different approach in the demonstrator than in the TRANSCOOP reference architecture. The reason was that we wanted to reuse existing software to cut down the development time for the demonstrator. At the TTMSS side, the pre-existing VODAK server API was extended by UAspecific, PA-specific, and TTMSS-specific functionality mentioned earlier. To integrate management tools and external applications, we extended the Java client API package for VODAK [Boll and Wasch, 1996] with operations to invoke these TRANS Coop-specific functions. With this approach it is possible to communicate from any Java application or applet with the TTMSS and vice versa. In the TRANSCOOP demonstrator, we used the extended SEPIA graphical user interface (implemented in Java) as a generic user front-end to the TTMSS.

6 THE TRANSCOOP SPECIFICATION ENVIRONMENT

6.1 INTRODUCTION

Frans J. Faase

Susan Even

Rolf A. de By

The system described in this chapter enables designers to define cooperative scenarios. It deals with the organization of the collaboration, as well as with the data sharing issues involved, including a range of particular restrictions that scenario designers may want to impose on the users.

6.1.1 Objective

When the TRANSCOOP project was proposed, we envisaged the need for the use of formal techniques in understanding the requirements of the application areas addressed by the project. The most important reason for this starting point was our wish to obtain a system founded on database technology, and capable of describing, carrying out and coordinating tasks in highly concurrent situations of cooperation. Previous experiences in this area had shown that architecture, and hence software, becomes rather complicated when genericity is the goal, and obtaining this genericity was precisely our objective.

In previous projects, we had observed that the use of formal techniquesalthough sometimes arduous in the beginning-would eventually lead to a more thorough understanding of the problems, and therefore to a better engineered

115




system. Similar experiences are well-documented in the literature, see for instance [Hayes, 1993].

One of the main problems in designing cooperative systems is to ensure consistency of shared data resources in the presence of users who need to concurrently access these resources. Resource sharing is a well-known problem in computer science, and numerous schemes exist within the fields of operating systems and databases, for instance. Unfortunately, many of these schemes either assume full isolation of users with respect to each other while they are accessing the resources, or they make the users themselves responsible for consistency. Cooperative systems specifically aim at bridging this functionality gap.

One may pose the question what the role of formalism and specification languages is in this field. In software engineering practice, if these techniques are used, they serve several purposes. The first, and arguably most important one, is that of rigid, unambiguous definition of required functionality. Such definitions are useful for requirements feedback, by discussing the consequences of the obtained specification with the end-user(s). In this approach, it is hoped that a good understanding of requirements, obtained early in the development cycle, prevents many errors and misunderstandings later on. It is no secret that the use of formalism forces the specifier to be precise, which leads to the important definitional questions to be answered.

A second purpose of formal specifications is their potential for the subsequent implementation process. The specification is then used as a 'contract' that defines the conditions that the implementation must meet. Reification and other refinement techniques exist to make this a formal process (with proof obligations et cetera) by itself, see for instance [Wordsworth, 1987]. In industrial practice, such processes of design are not carried out too often, but they are sometimes used in part in the more critical situations.

In cooperative scenarios, the role of specifications is another one. Here, the goal is not to prescribe the rules for the eventual implementation, but rather to define the rules of appropriate behavior of the actors (end-users) involved. This approach assumes that these users interactively develop their 'implementation' while they cooperate. Hence, there can be no a priori identified implementation, because cooperation between users cannot be defined up to a fine level of detail, as it requires to leave freedom of action for individual cooperators. As a consequence, the rules identified in the specification require checking at runtime, so to say at 'cooperation-time'. An obvious analytic question that then arises after the specification of the cooperation scenario has been obtained, is whether the specification admits to complete the scenario.

The inherent concurrency of cooperation, and the equally inherent issue of data sharing led us to study the combination of two formal specification languages: one that offers explicit notions of communicating processes (the process algebra LOTOS [Bolognesi and Brinksma, 1987]) and one that allows high-level definition of (shared) data items (the object-oriented data language TM [Bal et al., 1996, Balsters et al., 1993]). We felt both these notions were essential for

THE TRANSCOOP SPECIFICATION ENVIRONMENT 117

the TRANSCOOP application target area. Early on in the project, we investigated alternatives for merging these two languages [Even and Faase, 1994], and we used the language combination to describe distributed transactions [de By et al., 1995a]. The result of merging LOTOS and TM was the language LOTOS/TM [Even et al., 1996b]. The insights we obtained from these language design activities were translated into a specification language specifically for cooperation scenarios [Faase et al., 1996, Faase et al., 1997], which we describe in this chapter.

In Chapter 5, we made the distinction between 'workers-on-the-scene' and 'workers-behind-the-scene'. The first category was identified as the end-users for which the TRANSCOOP system offers a scenario that allows cooperation and data handling support. The second category was defined as the scenario designers who are responsible for the proper definition of scenarios. This, in summary, is the role of specifications in our system.

6.1.2 Chapter Overview

This chapter is arranged as follows. In Section 6.2, we discuss the consequences of the requirements study-as discussed at length in Chapter 4-for the specification environment. In Section 6.3, we proceed by introducing the chosen paradigm of specification of cooperation scenarios, and relating this to the requirements. Most of this chapter will be illustrated by a running example that we introduce in Section 6.4. We will also argue in that section why it does not fully allow to be supported by 'standard' transaction technology.

The body of the chapter can be found in Sections 6.5 to 6.8, in which we discuss the dimensions of the organization of the cooperation (Section 6.5), and the transactional aspects of the cooperation (Section 6.6). These dimensions were the most important points of departure for the specification language that we developed. The definition of this language CoCoA, which stands for Coordinated Cooperation Agendas, is provided in Section 6.8.

In the last part of the chapter, we reflect on formal language issues in Section 6.9. This section should be understood to provide some rationale for the design decisions that were adopted for CoCoA, as it links the characteristics of that language to some of those of LOTOS and TM. An important part of the work within the project was devoted to the design and implementation of a CoCoA tool set. In its present state, it is a prototype that addresses the most interesting research questions only. In Section 6.10 we identify these questions and discuss our attitude towards them.

We finalize the chapter with a section on related work (Section 6.11), and one where we discuss advantages and disadvantages of the chosen approach (Section 6.12).

6.2 REQUIREMENTS

The requirements of a specification environment in our context certainly include issues related to the ease of use, methodological support, and appropriateness


of the software tools offered. This, however, was not emphasized during the course of the project, as we felt many of these to be already well-studied in other tool development efforts, both in industrial and academic contexts.

Rather, the main focus regarding requirements for this part of the work was to provide the right primitives in the specification language to allow scenario designers to define their scenarios in a comprehensive style. A clearly understood semantics of the language, and a formal basis to allow various forms of analysis of specifications was also considered important. A full requirements study is presented in Chapter 2, and specification language issues are already discussed there. We restate the important findings of that study here.

The TRANSCOOP language should support the declaration/identification of the principle entities in the scene of cooperation: collaborators and collaborator roles, data types and entities, data operations, workspaces and data and message traffic between them. To address the more specific issues of TRANSCOOP, it should allow to define cooperation processes with transactional features. Further, we were trying to make the language suitable for a fairly broad spectrum of cooperation situations: those with more structure and regulations found in workflow applications, those with relatively homogeneous data operations but free-form invocation patterns as found in cooperative authoring, and those with heterogeneous data operations and more restricted invocation patterns as found in design for manufacturing. Several other descriptions have been applied to characterize the spectrum, but essential to any of these characterizations is the different levels of activity parallelism, the amount of regulation of the collaboration, and the number of data types involved in it. There is another important discriminating factor, which is the level of geographic distribution of collaborators and/or data entities, but this issue was largely ignored in the design of the specification language.

Our conclusion from the above discussion is that we need a flexible and expressive language, capable of handling data, data operations, cooperative processes, et cetera. Essentially, the language should feature process notions and complex data type notions. Further, it should be equally appropriate for fixed structure cooperation types as well as free-form cooperation types.

6.3 A COOPERATIVE SPECIFICATION LANGUAGE PARADIGM

6.3.1 The Essential Building Blocks

In Chapter 2, the general approach and paradigm of TRANSCOOP was discussed. We now focus on the paradigmatic issues of specifications of cooperative work. The TRANSCOOP specification of a cooperation process is called a scenario.

We view a cooperation as an interactive process of a number of actors, who essentially are people who have agreed to work together. This cooperation is supported by a means through which the actors can communicate, and a data storage facility that can be used for storing (intermediate) results of the cooperation. The data storage facility consists of workspaces, of which we


have one each for each actor involved in the cooperation, plus a single, shared workspace for the overall scenario. The actor workspace is private and cannot be used by others. The shared workspace (called the common workspace in the COACT transaction model, see Chapter 7) can be accessed by all actors, and is the medium via which intermediate results are exchanged between actors, and which typically holds the resulting product of the cooperation process. Actors and their workspaces are the most elementary static notions of a scenario.

We must not ignore the data resources that are the subject of cooperation. In the specification language, we have assumed that a complex object base schema is available for inclusion in a scenario specification, and for our discussion here it can be considered an integral part of it. This object base schema is best viewed as a complex data type database schema. This schema provides an object-oriented definition of all the object types needed for doing the work. This explicitly includes methods for object manipulation. A (private or shared) workspace can be understood as an object base that adheres to the schema. Thus, at scenario definition time, it is required to obtain such a complex object base schema.

Quite evidently, the actions used to carry out cooperative work need to be described as well. In the context of actors, their workspaces and an additional shared workspace, operations of three kinds are identified. Data operations are standard data manipulations that take place in a single workspace, which can be either private or shared. They are assumed to have been defined in the object base schema. Data exchange operations form a second class of operation, and allow actors to import data from, or export data to another workspace, which may be the shared workspace. This provides actors with the capability of exchanging (intermediate) results between them. A last class of operation is formed by the communication operations, or communications for short, which allow to notify the actor community of certain events.

This provides us with the core elements of a cooperation scenario. In the following, we discuss the paradigm of structuring the cooperation process.

6.3.2 Organizational Aspects of a Cooperation Process

The organization of a scenario is typically described first, as this very much requires a top-down technique. Its key primitive is the step, a task-wise coherent group of actor activities that helps to progress the scenario. Multiple actors can be active in a single step, and the step defines which operations can be performed by its actors. The scenario organization may consist of a single step, but more commonly, multiple steps are involved. These steps can be defined to be active in sequence or in parallel, or in any arbitrary sequential or parallel combination, for which the language provides operators.

The allowed operations within a step are just listed, and do not impose an invocation order in the scenario. This lack of enforcement allows the needed freedom of action for its actors: they can choose whatever operation is allowed


within the step. If two steps are active at the same time, this leads to an accumulation of operation options for the actors involved.

When the scenario designer wants to add more organizational structure to the step, there is the possibility to define sub-steps within it. The set of allowed operations for the step itself then becomes the union of those of its sub-steps. It is the case that the termination of a step forces all its sub-steps to terminate. The definitional capability of sub-steps does not provide extra expressivenessa similar organization could have been defined without nested steps-but it serves clarity of specification.

A final word about the organization specification should make clear how the actors go from one step to another, i.e., how they enter and leave steps. This is where the communications come into play, and we shall illustrate in which way below.

6.3.3 Transactional Aspects of a Cooperation Process

Steps are used to describe a rough division of the work within a scenario, but CoCoA provides additional means to detail out what is and is not allowed in the scenario. This is achieved by using the transactional machinery of the language. There are three sets of linguistic tools for this, all in the form of constraints.

Termination constraints can be used to indicate a condition that should hold before a step can be exited.

Ordering constraints are regular expressions made up of operation invocation patterns, i.e., operation names with partly filled in parameter lists, in which the parameters are variables over an appropriate domain. A specific semantics is attached to these constraints which makes them a good tool for further detailing out the actor activity.

History constraints are specific to TRANSCOOP's transaction model, as they allow to refer to the history of operations within a workspace. A history constraint defines a condition with respect to a workspace's history that should hold to allow the exchange of certain data between two workspaces. Some of these exchanges should not be allowed because the two histories involved may be irreconcilable with each other. We come back to this issue in Section 6.6.4.

All three types of constraints will be illustrated in the next example.

6.4 EXAMPLE COOPERATIVE SCENARIO

The scenario that we use as an illustration throughout this chapter describes a process of document authoring. The collaborators are the editor and a number of co-authors, who have agreed to write a document, which is afterwards reviewed by a reviewer. The editor plays an important role in the organization of the work: slhe decides who will be the author(s) for which chapter, and assigns tasks to them. A task consists of writing a chapter, and multiple authors can be assigned to work on a single chapter. The editor can be one of the authors. The authors themselves are free to organize their work as they see fit, but need


to take care that the final version of the chapter has been spell-checked. The editor also decides when the document is ready for submission to the reviewer. This reviewer will judge the document, and decide whether the document is acceptable, should be discarded, or needs some parts to be rewritten. In the latter case, the editor will resume the work, and can assign tasks to authors again.

The document in the making is stored in the shared workspace, but all private workspaces also keep a version of it. Any change made by an author to the document is, at first, only applied to her jhis private version. Data exchange operations can later be used to make the changes available to other authors.

A gradually evolving document with multiple authors is a typical example of a process that cannot easily be accommodated by standard transaction technology. It would perhaps be possible to do this, but it would require a quite specific application and careful coding.

The writing process is a long-lived activity, perhaps with a duration of several months. There exist no clear 'checkpoints' at which the complete document can be considered consistent, and at which previous changes to it are considered committed. In fact, there may not be a notion of 'complete document' until the very end of the scenario, because the effort and results are scattered over multiple workspaces. Standard transactions require that concurrent changes to data are serializable, and this seems too strict a requirement for document authoring as we describe it here.

We opt for describing the scenario organization with three separate steps. The preparation step is used by the editor to prepare the title page and write the introduction. In the writing step, the editor assigns the tasks of writing a chapter to groups of authors, and during the review step the reviewer carefully inspects the document.

The editor chooses the authors from a set of potential authors, which is determined at the start of the scenario. Whenever the authors agree that they have completed their work, they inform the editor about this, and the task is considered completed. During the writing step, any number of tasks can be in progress, and an author can be involved in any number of tasks concurrently. The authors of a chapter are responsible for the organization of their work; they nay be writing concurrently and may also concurrently add annotations to the chapter text.

During the review step, the reviewer reads and judges the document. Although the reviewer cannot modify the text of the chapters her jhimself, s jhe can make annotations for the editor, in those places where revisions are deemed necessary.

In the overall process, a number of decision points require the collaborators (the editor, the reviewer, or an author) to notify others of events, such as chapter completion. Behind the screens, this influences the control flow of the scenario. In later sections, we will see what this means specifically. For each actor role ('ed', 'a', and 'r' in our example, standing for editor, author and


reviewer), we identify which communications, i.e., which event notifications, they are allowed to use. These event notifications are listed in Table 6.1.

Table 6.1 Allowed communications for editor, authors and reviewer in the document writing scenario

ed : introWrittenO ed : startTask( c,ag) a: completeTask(c) ed : readyWritingO

r : acceptDocO r : rejectDocO r : reviseDocO

In the above, the parameter c stands for a chapter, and ag is used to indicate the author group assigned to write the chapter. In the case of the startTask communication, for example, it is only the editor who can issue it, and s/he needs to identify the chapter and its group of authors.

Each communication is issued by a single actor and it changes the state of the scenario execution, usually by causing one or more steps to be started or terminated. We discuss the details below.

To ensure that the writing process produces a document that meets certain quality criteria, it is required that the final version is spell-checked. Furthermore, all annotations should have been processed and hopefully integrated in the text. Therefore, it is taken as a requirement that all authors have removed all annotations in their chapter(s), which we will interpret to mean that they have been taken care of. These requirements are examples of termination and break-point constraints.

The main data operation offered to authors is editing the text of a chapter. They are, however, also allowed to annotate chapters, i.e., granted the right to make marginal notes. These annotations can be exchanged together with the chapters, or separately. Clearly, there exists a subtle relationship between the chapter version and its annotations, since annotations are suggestions for improving the text, and these annotations will be removed after they have been dealt with. This results in a complex notion of chapter version, because annotations can be added and removed independently from changes to the text.

For our simple example, it suffices to consider the title page, the introduction, the conclusion, and the bibliography as ordinary chapters. Quite evidently, we could have opted for a higher resolution of text fragments, for instance identifying sections, paragraphs, tables and figures as finer-grain subjects of the writing process, but this would have added only more complexity to the example, with little added illustrative value. In Table 6.2, we list the data operations that are available to the actors in the scenario. Each of these operations takes effect in a single workspace only.

All operations require parameters: a stands for the author who issues the operation, c identifies a chapter, t stands for text used for editing, and an stands for an annotation text.


Table 6.2 Available data operations for authors in the document writing scenario

a: addChapter(c) a: deIChapter(c) a: editChapter(c,t)

a: spellCheck(c) a: addAnnotation(c,an) a: remAnnotation(c,an)

Finally, we look at data exchange operations. These are either import or export operations, which exchange chapters or annotations. If a chapter text is exchanged, we assume all its annotations are exchanged with it. In Table 6.3, all possibilities are listed.

Table 6.3 Allowed data exchange operations for authors in the document writing scenario

a: import Chapter(c) from w a: export Chapter(c) to w

a: import Annotations(c) from w a: export Annotations(c) to w

Each of these data exchange operations takes parameters: in addition to those discussed above, w stands for a workspace identification.

6.5 DEFINITION OF ORGANIZATIONAL ASPECTS

6.5.1 Overview of Scenarios, Procedures and Steps

The organizational aspects of a scenario determine who is allowed to do what operations at which stage of the scenario execution. In describing the organizational aspects, there are three important dimensions: actors, activities, and time.

A CoCoA procedure defines the organization of activities within a scenario. It lists a number of steps and a number of transition rules. The latter define how the former are chained together, and define the coarse-grain control flow of the procedure. Intuitively, a step represents a unit of work in the procedure. Each step definition defines its entry, interrupt, signal and exit interaction points, at which interaction events of other steps can take place. This form of interaction is mandatory: the initiator of such an event forces the receivers to follow. The allowed interactions are defined in the transition rules. Entry interactions activate the step; exit interactions deactivate it. There may be several of each of them. A step allows its actors to execute operations if and only if it is active. Interrupts can be received and signals can be sent only while the step is active. At the very start of the procedure, all steps are inactive.

An interaction event in the formal model of steps is a scenario state, transition in the state machine defined by the procedure. Each state of this machine characterizes which are the users, which steps are active, and which are the enabled interaction points. The transition rules of the procedure govern which


are the allowed state transitions in the model. The exact semantics of the different types of interaction is provided below.

In our informal description of the authoring example, three steps were already identified: preparation, writing and review. Furthermore, each task of writing a separate chapter is considered to be a (sub-)step in our CoCoA specification, which we will discuss further below.

As an aside, we remark that in some transactional workflow techniques, steplike structures serve also to define transactional boundaries. This is not the case in CoCoA, where steps only help to organize the work in smaller units of activity. In other words, the deactivation of a step does not imply any commits or aborts of data operations invoked during the time the step was active.

6.5.2 Procedure Definition

As an illustration, consider the partial specification provided in the code below. Its three top-level steps are preparation, writing and review. All have entry and exit interaction points; the first, for example, has an exit (interaction point) done, and the second has an entry point start. These two interaction points are made to coincide by the procedure's second transitionscenario,transition rule (See also Interaction point) rule, i.e., the line reading 'on preparation.done do writing. start'. This example illustrates a simple sequence of two steps, but more elaborate control flow can be built. As an aside, we mention that these definitions can be carried out in a graphic user interface, which makes their specification less cumbersome. The typical output of this user interface is depicted in Figure 6.1. The textual structure is shown below.

Procedural specification of scenario (Ellipses indicate left out specification text.)

procedure (ref: reviewer, ed : editor, authors: lP' author) [in start out cancel, done)

begin workspace document: cda

step preparation[in start out done) begin

end

step writing[in start out done) begin

parallel( ch : chapter) step task[in start(lP' author) out compl) begin

end endpar

THE TRANS COOP SPECIFICATION ENVIRONMENT 125

Figure 6.1 A graph representing the specified scenario

prepare writing review

done ~, "" start

,PI

start ~ start done~ start

on start enable when ed issues startTask(c, a_s)

done 8ccePt~ rej~ct ~ cancel reVISe ___

iff (as subset authors) do task(c).start(a-B), when ed issues readyWritingO do done

endon end

step review[in start out accept, reject, revise] begin

end

on start do preparation. start on preparation. done do writing.start on writing. done do review.start on review. accept do done on review. revise do writing.start on review.reject do cancel

end

The procedure itself also has entry and exit interaction points, and these are declared in square brackets on the header line. They signal start and end of the procedure, and are used to declare interaction with the procedure's step interaction points. When the scenario is instantiated, its start interaction point is enabled. Clearly, the specification must identify at least one top level step that becomes active as a consequence, and the first transition rule does precisely this.

Our scenario can terminate with two possible outcomes: cancel and done. The procedure header also defines the different roles of actors in the scenario, as well as the name and type of the shared workspace.


6.5.3 Operation Enabling

A step definition defines which data operations, data exchange operations, and communications can be enabled for the users of the scenario inside the step. This will allow them free-form usage: enabled operations can be invoked any number of times, and in any given order. The enabling takes place only when the required interaction takes place, as defined in the step. There exists no explicit disabling in the language: when a step terminates all permissions issued from it are automatically withdrawn. Only by invoking (enabled) communications, can one or more other steps become activated or deactivated. We discuss this issue at length below.

Data operations and data exchange operations are enabled inside a step for a specific user role, using the following syntactic construct:

on (intpoint) enable (user role) : (operation list) endon

This indicates that whenever the interaction at intpoint occurs, the user in the role of user role is allowed to perform the listed operations, up to the point where the step terminates. The specification code for the preparation step below shows examples; a literal argument value for an operation indicates that the user is allowed to invoke an operation only with the provided value.

step preparation[in start out done] begin

on start enable ed : addChapter(ltitle") , editChapter(ltitle", -), addChapter(" intro ") , editChapter(lintro", -), export Chapter("title") to document, export Chapter("intro") to document when ed issues introWrittenO do done

endon end

An interaction at start enables four data operations which the editor (identified by ed) may perform in her/his private workspace: the operations addChapter and edi tChapter on the title, and on the introduction. As before, the symbol' _' is used to indicate that no restrictions are placed on the value of a parameter in that position. Two data exchange operations are enabled by interactions at the start interaction point. Using these operations, the editor can export the contents of her/his private workspace to the shared workspace (called 'document'). Further enabling governs the communication operation introWri tten. In the example, the editor can use the introWri tten communication to exit the step. This initiates the exit interaction marked done, which deactivates the step. The reader should observe that no ordering constraints are imposed by the enabling constructs; such constraints are specified by execution rules, which are discussed in the next section.


Another enabling example was already present in the writing step of the procedural scenario specification of page 124. Only by invoking communications (once enabled), one or more steps may become activated or deactivated. The enable construct inside the body of the step writing provides two eventcondition-action rules, which specify how the tasks are activated by the editor by means of the communication start Task, and how the editor can terminate the whole step through the communication readyWriting.

Whenever the writing step is active, the editor can start the writing tasks for the various chapters through the communication startTask by supplying the name of the chapter and the set of authors in charge as actual parameters. The condition of the event-condition-action rule specifies that the set of authors must be a subset of the available authors, which was bound to the authors parameter at the instantiation of the scenario. For each of the writing tasks, a step task is activated. This is specified by placing the step task inside a parallel clause (indicated by the keywords parallel and endpar), which is parameterized by ch of type chapter. By doing this, we indicate that any number of instances of the step task can be activated, each with a different value for the parameter ch. This is an example of a parallel step activation multiple parallel step activation. A set of authors is transferred to the step task via an additional parameter attached to the interaction point start. This is how values are transferred between steps. Below, we show how this value is used in the enabling expression inside the step task. When the editor terminates the writing step by invoking the communication readyWriting, any remaining active task steps are deactivated as well.

We may also look at operation enabling for authors in the writing task as illustrated in the specification code below.

step task[in start(1P' author) out compl] begin

on start(tas) enable for a in tas allow a :

addChapter(ch), editChapter( ch, _), addAnnotation( ch, _), remAnnotation( ch, _), import Chapter(ch) from document, export Chapter ( ch) to document,

when a issues completeTask(ch) do compl endfor for aI, a2 in tas allow al :

import Chapter(ch) from a2, import Annotations(ch) from a2

endfor endon

end


Interactions at the start interaction point must provide a value of type 'IP' author' (Le., a set of authors) as a parameter. This value will be bound to variable 'tas' of the clause 'on start (tas) enable ... ' when such an interaction takes place. A start interaction enables a number of operations for the set of authors given as a parameter. Authors can import and export chapter text to and from the shared workspace (the document). Furthermore, each author working on the chapter may import the chapter text and annotations from other authors' private workspaces.

The examples presented here do not cover all aspects of CoCoA. In addition to the entry and exit points, the language also has interrupt and signal interaction points. Interrupts do not activate a step, and only have an effect if it is already active; they are without meaning if the step is not active. (Interrupts and additional entry interactions may lead to further operations being enabled, i.e., they have a cumulative effect.) Signals, on the other hand, can only originate from active steps, and do not deactivate the step. Through these additional interaction points, the actors in the steps executing in parallel may grant each other additional capabilities.

6.6 DEFINITION OF TRANSACTIONAL ASPECTS

6.6.1 Overview

Transaction techniques essentially deal with providing users consistent views on the data set. The TRANSCOOP view on transactions is a permissive one that is liberal in allowing data operations, and tries to fix problems only when they occur. The underlying techniques rely on maintaining the history of data operation invocations for each workspace. Merging and conflict resolution takes these histories as input, and produces new histories.

Data consistency preservation is governed by two types of rule in CoCoA, execution rules and history rules. The execution rules pose constraints on the order of data operation invocations in the workspace histories. The operation enabling mechanism of steps already controlled this to some extent, but with execution rules, a finer level of detail can be reached. In our example, a chapter can only be edited when it exists, which means it should have been created, but also that it has not been removed yet.

A workspace history may contain both invocations executed by the workspace owner, and invocations that were imported from any of the other workspaces. The history rules specify constraints to preserve consistency when partial (data) results are exchanged between workspaces. In our example, edit operations are not commutative, which means that one cannot import an edit operation on a chapter version which has been edited in the mean time.

Although partial results are exchanged by exchanging the operations on the data instead of the data itself, the end-users of the scenario think rather in terms of data than in terms of operations on the data. To bridge this gap, the definition of data exchange operations is added to the language. In the


following sections, the execution rules, data exchange operations, and history rules are discussed.

6.6.2 Execution Order Rules

Execution (order) rules pose restrictions on the order of data operation invocations in the histories associated with the workspaces. Our intention is to express restrictions such as: "an edit operation on a chapter cannot be executed unless that chapter exists." Instead of trying to specify all restrictions in a single rule, CoCoA allows the specification of many rules in parallel, each rule addressing only a single restriction. An execution rule is an extended regular expression over operation invocation patterns. By definition, a rule only applies to those invocations that match one of the patterns used in the rule. Other, non-matching invocations in the history are ignored for this execution rule; it is as if they have not been executed. A history is valid only if it is correct for all execution rules. What this means, we define below.

In the extended regular expressions used in the execution rules, we use standard syntax for the postfix operators of sequential ordering (";"), one or more repetitions ("+"), and zero or more repetitions ("*"). Bracket operators indicate optional clauses ("[ ... J"), or syntactic grouping ("( ... )"). The elements of our regular expressions are data operation patterns, which may include values and variables at parameter positions.

The following execution rule from our example states that a chapter can only be edited, spell-checked, or removed after it has been added to the document, and that a chapter cannot be edited or spell-checked anymore when it has been removed. There is no restriction on how often a chapter may be edited and spell-checked.

data operation order chapter ..rule :

foraH c : chapter order addChapter(c);

(editChapter(c,_) I spellCheck(c))*; delChapter( c)

The following execution order rule states that annotations can only be made to a chapter after it has been added to the document, and that all annotations have to be removed before a chapter can be removed.

annotation...rule : foraH c : chapter, an : annotation order addChapter(c);

(addAnnotation( c,an); remAnnotation( c,an)) *; delChapter( c)

The semantics of these rules is defined in terms of what we find acceptable histories. For this, we define the notion of correctness.

A history can be viewed as a sequence of invocations. A sequence is the prefix of another sequence if it fully coincides with a first segment of the second. An


invocation pattern matches an invocation if the parameters provided in the pattern coincide with those of the invocation, and the operation names are equal, obviously. Universal quantification in execution rules allows to define many rules at once, namely one rule for each value of the universally quantified variable. In the technical discussion of this section, the reader should consider an execution rule as one without universal quantification, as this allows us a more intuitive discussion. Inclusion of quantification is straightforward since for a particular history, only a finite set of universal quantifier-free execution rules needs to be checked, as the invocation patterns in the history, determine values for parameters in the operation patterns of the rules. A history restricted to an execution rule is a (not necessarily contiguous) sub-sequence of the history that includes all and only those invocations that match patterns of the rule. A history is called correct with respect to an execution rule, if and only if its restriction to that rule is a prefix of at least one of the sequences generated by the regular expression.

6.6.3 Data Exchange Operations

In Section 6.5.3, we saw some examples of import and export operation enablings, such as the following, which can be done by one of the authors involved in a particular task:

for aI, a2 in tas allow al : import Chapter(ch) from a2, import Annotations(ch) from a2

Here, 'ch' stands for the chapter being edited, 'tas' stands for the set of task authors, and 'a2' stands for a second author's workspace. The two expressions 'Chapter (ch), and 'Annotations(ch)' refer to data that is to be exchanged, and thus, implicitly to sets of operations. Such a set can be identified using the select construct in CoCoA. For example, to identify a set of operations 'Chapter (ch) " the following definition can be used:

data exchange operations Chapter(c: chapter) = select addChapter(c), editChapter(c,_),

spellCheck(c), deIChapter(c)

This part of the code specifies that all add, edit, spell-check, and delete operations on the chapter parameter 'c' are selected from the current history.

6.6.4 History Rules

The transaction model, as we shall see in Chapter 7, uses operation history techniques to maintain data consistency. The exchange of consistent partial results between workspaces, for this reason, requires to know about the absence or presence of commutativity relationships between the data operations. Two commutativity relationships need to be specified for the operations: the backward commutativity, which is used to extract consistent partial results from


a history, and the forward commutativity which is used to check whether partial results can be added to a history without introducing inconsistency.

The notion of backward commutativity, as defined in [Weihl, 1988], is used to determine which operations depend on each other, but it is the specifier who has to indicate which pairs of operations commute backwards. The user who invokes a data exchange operation implicitly selects in so doing an initial set of recently invoked operations on the selected data item. Given this set, the transaction model calculates its minimal transitive closure with respect to the defined backward commutativity conflicts. This identifies the relevant sub-history of operations that also have to be exchanged.

Another algorithm in the transaction model determines how this relevant sub-history can be merged with the receiving history such that a consistent result is produced. The notion of forward commutativity, also defined in [Weihl, 1988], is used to detect conflicts between the relevant operation sub-history and the operations in the receiving history. If no conflicts are present, the two histories are merged. In case there are conflicts, the user is given (by the runtime environment) the option to either choose a smaller set of operations to be merged, or to undo operations present in the receiving history. For details about the history merging mechanism of the transaction model we refer to Chapter 7. We remark that in an important follow-up paper [Weihl, 1993] an generalization of these commutativity concepts, which are shown to be less implementation-oriented, has been described.

In CoCoA, commutativity relations are specified by enumerating potential conflicts, as these are much less numerous than non-conflicting situations. It turns out that in a substantial percentage of the conflict cases, lack of forward commutativity implies lack of backward commutativity, and vice versa. Therefore, CoCoA allows to specify both properties in a single rule for a pair of data operations. In cases where we have one type of commutativity conflict, but not the other, this is explicitly stated in the rule. An example follows.

In our scenario, we define the following commutativity conflict rules for operations on chapters as a whole. In all these cases, we have both types of conflict.

history rules forall c : chapter non-commutative addChapter(c) and addChapter(c), non-commutative addChapter(c) and editChapter(c,_), non-commutative addChapter( c) and spellCheck( c), non-commutative addChapter(c) and deIChapter(c), non-commutative editChapter( c,_) and editChapter( c,_), non-commutative editChapter(c,_) and spellCheck(c), non-commutative spellCheck(c) and spellCheck(c), non-commutative deIChapter(c) and deIChapter(c)

There are no commutativity conflicts between the data operations changing the text of a chapter, and the data operations which add or remove annotations. There is, however, a implicit relationship between the data operations


remAnnotation and edi tChapter if we assume that annotations that have been removed are incorporated in the next version of the text. This commutativity conflict, which is enforced by the application semantics, is defined in the following history rule:

forall c : chapter, t : text, an : annotation non-commutative remAnnotation(c,an) and editChapter(c,t) backward true forward false

At this point, it is required to discuss in slightly more depth what the differences between forward and backward commutativity are, although this will be further discussed in Chapter 7. The lack of backward commutativity between two operation invocations in a single history means that there exists a data dependency between the two operations. This characteristic is used to identify which operation invocations constitute the relevant sub-history when we want to perform a data exchange between two workspaces. Remember that data exchange is implemented by exchanging partial histories, not by exchanging data itself. The lack of forward commutativity between two operation invocations is a characteristic that is used to do history merging, as will be explained in Chapter 7. In the above example, the backward clause tells us that if we want to exchange a chapter text, this needs to be implemented as the exchange of a partial history consisting (at least) all editChapter and remAnnotation operations on that chapter. The forward clause tells us that there are no problems caused by this operation combination in history merging.

6.7 INTEGRATION OF ORGANIZATIONAL AND TRANSACTIONAL ASPECTS

In the previous sections, we explained how specific execution order rules can be specified. Execution rules are, just like the operation enabling statements, only descriptive and not prescriptive, or in other words, they do not express what must be done, but only what can be done.

CoCoA provides termination constraints to describe cases in which we want to require that a condition holds before the step finishes. In the language, these constraints are added to the transitions in the form of a predicate. They are added to step definitions only when needed, and use value labels that are added in-line to the execution order rules.

A value label assigns a state value to the execution order rule at a certain position, and can be viewed as a means of rule progress administration. The reader is referred to the example given below. There, the execution rule chapter ...rule is augmented with a value label, given in quotes, which is valid after each successful invocation of edi tChapter. This value label is consecutively used in the termination constraint of the task step, as defined in Section 6.5.3. Value labels are allowed in positions immediately following invocation patterns in the execution rules.

data operation order


chapter _rule : forall c : chapter order addChapter(c) ;

(editChapter(c,_) "edited" I spellCheck(c))*; remChapter( c)

The string value "edited" following both the data operation patterns addChapter(c) and editChapter(c,J, indicates that the chapter is in the edited state directly after these data operations have been carried out. Patterns without such a label cancel any previously set labels in the rule.

A query expression on the states of the execution rules can be attached to the transitions between steps in the procedure definition to describe breakpoint and termination constraints. For example, a query expression on the state of the above rule can be added to the condition of the final transition of the procedure definition to enforce that all chapters have been spell-checked.

As an example, consider the condition that the editor can only terminate the overall writing step when all chapters in the shared workspace have been spell-checked:

step write[in start, revise out done] begin

on start enable

when ed issues readyWritingO iff forall ch : chapter

query document on chapteLrule(ch) <> "edited" do done

endon end

Here, a query expression is used to check the status of the execution rule with respect to the respective chapters. If the condition is not met, the transition does not take place. The expressions following the rule name indicate the values for the parameters mentioned in the forall-clause. In case the current position of the rule is not labeled, the query expression returns an empty string value, as a matter of implementation.

If we would like to state that a writing task can only be completed if all the annotations have been removed from the chapter-thereby assuming they have been processed-the addition of the following iff-clause suffices:

when a issues compIeteTask(ch) iff forall an : annotation

query document on annotation..ruIe(ch, an) <> "unprocessed" do compI


6.8 THE COCOA LANGUAGE

In the above, various aspects of the CoCoA language were explained. We now discuss how all of these, and some additional features, combine to produce a single specification. The code below provides the skeleton of the complete scenario specification for our example.

scenario write_document includes authoringDB data types chapter, text, annotation

database operations addChapter( chapter) del Chapter ( chapter) editChapter( chapter, text) spellCheck( chapter) addAnnotation( chapter, annotation) remAnnotation( chapter, annotation)

workspace types cda = { addChapter, edit Chapter, delChapter,

spell Check, addAnnotation, remAnnotation }

user types reviewer using cda, editor using cda, author using cda

communications introWrittenO, startTask( chapter, IP author), completeTask( chapter), readyWritingO, acceptDocO, reviseDocO, rejectDocO

data exchange operations ...

procedure ...

execution rules ...

history rules ...

end write_document

A CoCoA specification starts with the scenario keyword followed by the name of the scenario, and ends with the end keyword, followed again by the scenario name. Right after the scenario name, at the top of the scenario, references to one or more (object-oriented) database schemas may be included, following the conventions of the TM language. In the case of the example, it is the authoringDB database schema.

The data types section identifies those types from the included database schema(s) that playa role in the scenario. We hereby explicitly declare these such that they can be used in the scenario.


Data operations are either defined as methods in one of the included database schemas, or by a data operation definition clause. Such a clause starts with the keywords 'database operations' followed by the names of the data operations, and the argument types in brackets.

A next element of a scenario specification is the definition of the workspace types. Workspace types are used in the definition of user types, and define a set of data operations. The set of data operations that can be invoked in the workspace of a user is restricted by this workspace definition. The common, shared workspace also has a workspace type. In our example, only one workspace type is defined.

The remaining parts of the specification were discussed in previous sections.

6.9 REFLECTIONS ON THE FORMAL MODEL OF COCOA

One major reason to use a formal specification technique is to find design flaws at an early stage of the application development process. We especially looked at checking run-time properties at design time. Such properties can be divided into generic properties, such as termination, and user-defined ones, such as "will all the chapters be spell-checked at the end of the scenario?" To a certain degree, some generic properties can be subjected to static analysis of the scenario specification, by checking how steps are connected through transitions, ignoring the conditions on the execution order rules which may be set on the various communication operations. Evaluation of the latter requires essential run-time information.

A more accurate analysis can be performed by generating the state space of the organizational state of the scenario. In practical examples, generating the complete state space may be impossible, and undesirable. In our example, any number of tasks of work on a chapter can be activated. For design-time analysis, we might decide that a maximum of three chapters is sufficient to make conclusive statements about the behavior of the scenario with any number of chapters.

These schemes require us to provide the formal semantics of the language first. Section 6.9.1 below discusses how the procedure specification is mapped to a state transition system. This mapping has been automated in one of the tools developed in the project.

When the organizational aspects are analyzed in isolation, the blocking effect of termination and break-point conditions are ignored. For this reason, it may be useful to check if these conditions can be met, using the properties of the execution order rules. Likewise, user-defined statements about the final result of a scenario can be investigated. This is discussed in greater detail in Section 6.9.2.


6.9.1 Formalization of the Organizational Aspects

The organization of a scenario is represented as a state transition system. We discuss first how the state of a scenario instance is represented, and then we show how state transitions can be derived from the procedure definition.

A state of a scenario instance S consists of four parts, U, A, E and T:

• U: The assignment of users to user role parameters, i.e., the set of actual users and their roles. These parameters are assigned a value when the scenario is instantiated, and do not change during the execution of the scenario instance.

• A: The set of steps currently active in the scenario. Each active step is represented as a structure of which the first component is a list of step names identifying the hierarchical position of the step in the procedure definition, and the second component is a (possibly empty) list of values for the parallel clause parameters that enclose the step.

• E: The set of enabled interaction points that have operation enabling statements attached to them. Each point is represented as a structure with four components. The first two components are the same as for a step. The third component is the name of the interaction point, and the fourth component is a list of values for the point parameters.

• T: The terminations state set. This is a possibly empty set of names of exit points of the state. This set is empty if and only if it represents a running scenario instance.

Based on this state representation, the set of enabled operations is determined. The initial state of a scenario instance is based on the procedure's entry point(s) and the transitions following from it. All following state transitions are initiated through communications. A communication can only occur at one place in the procedure definition. From this, we construct a set of state transition functions, one for each communication. To obtain a state transition function for a given communication, we must follow all the transitions from where this communication is invoked in the procedure definition. A step is deactivated when a transition occurs at an exit point that is part of the step, or of one of its surrounding steps. A step is activated when a transition occurs at an entry point. Transitions that follow an interrupt point of a step that is not yet active are ignored.

Bellow we give a pseudo-code algorithm, which, for a given state Sand communication c, calculates the effects on the A and E components of state S:

Scenario-State-Change ( S, c) P := points_oLcommunication(c)j while not_empty(P) {

for all p in interrupt_pointsin(P)

}


{ if step_of(p) in A { E := E U {p}; } }

for all pin entry_points_in(P) { A := Au {step_of(p)};

E:=EU{p};} for all p in exiLpointsJn(P)

{ A := A - step_and_sub_steps_of(p); E := E - points_of(step_and_sub_steps_of(p)); }

P := pointsJeached_by_transitions..from(P);

Once the state transition model is established, it can be used to perform state space analysis to find out whether the scenario can terminate, and whether there are no blocking states. It is also useful for checking whether the specified behavior matches the behavior intended by the specifier. As the mapping does not take into account the state of the workspaces, it does not match with the run-time behavior. The next section describes how reasoning about the execution order rules can give an even more accurate analysis of run-time characteristics.

6.9.2 Including Transactional Aspects

The mapping as described in the previous section does not account for transactional aspects. This means that scenario instances may not terminate when the above analysis would indicate that they do. Also, questions like whether the last version of the chapters will be spell-checked, cannot be answered.

To make such additional claims, we can analyze the conditions under which the communications do occur, and compare these with the execution order rules. In our example, the readyWriting communication inside the writing step has a condition attached to it, which queries the chapter ..rule. An analysis of this rule reveals that the condition is invalidated by the addChapter and edi tChapter operations, and made valid by the spellCheck and delChapter operations. By querying which operations are enabled at the various paths reaching the state in which the readyWri t ing communication is enabled, we can verify that the condition can be met.

Likewise, if we would want to verify whether all chapters are indeed spellchecked when the scenario terminates successfully, we have to check this when the scenario terminates at the done exit point. Analysis shows this condition is enforced when the writing step is deactivated by the readyWriting communication, and that step review is activated next, which can lead to a successful termination of the scenario. We know that the reviewer is only allowed to make annotations in the review step, which in turn means that the operations addChapter and edi tChapter are not enabled. From this, we can conclude that all the chapters will be spell-checked when the scenario terminates on the done exit point.


6.10 THE COCOA TOOL SET

An important part of our efforts during the TRANSCOOP project went into the realization of a set of tools surrounding the CoCoA language. Besides means for entering specification code in a controlled way, it provides tools for both static and dynamic analysis, and also a pair of compilers (specific to the TRANS COOP run-time system), which generate executable code.

Specification code can be entered through a Graphical Scenario Editor. It features, amongst others, a step-as-box interface that allows a user-friendly way of drawing step definitions and their interactions.

The Static A nalysis Tool is an extended type checker that incorporates a number of static checks such as scoping of variables, operations and communications. Some of these checks go beyond the usual parser checking.

The Dynamic Analysis Tool is a simulation environment in which the specification can be symbolically executed. The emphasis in this tool is on the state space of the organization of the scenario, more so than on the transactional aspects.

In Chapter 8 we discuss the tools provided in more detail.

6.11 RELATED WORK

Several extended transaction models have been designed to deal with the relaxed correctness requirements found in cooperative systems. See, for example, the open nested transaction model [Weikum and Schek, 1992, GMD-IPSI, 1995], transaction groups [Nodine et al., 1992], and the ConTract model [Reuter and Wachter, 1991, Schwenkreis, 1993]. Although these transaction models support long-lived, multi-participant transactions, they are limited in their support for the organizational aspects of cooperation. In contrast, workflow applications typically offer plenty of support for the organization of activities. During the past decade, several workflow systems have been extended with transactional abilities. See, for example, the TriGS system [Kappel et al., 1995], and the Exotica system [Alonso et al., 1996]. However, the extension of workflow systems with transactional properties is not sufficient to model cooperation: the tight coupling of the control flow and transactional behavior in these systems limits the types of behavior that can be modeled. In addition to workflow, there are other domains for which cooperative applications have been developed, such as software engineering and cooperative document authoring (Johnson, 1994, Prakash and Shim, 1994]. Although these applications have good support for various forms of cooperation, they typically do not offer transaction support.

The transactional features of CoCoA are based on the CoAct transaction model [Rusinkiewicz et al., 1995]. The CoAct model assumes that each scenario instance is an ACID transaction. All data operations are considered to be ACID sub-transactions within a scenario execution. In the CoAct model, there are no 'transactional' conflicts between operations executed in different workspaces; conflicts can only arise during an attempt to merge operations


from different workspaces [Wasch and Klas, 1996]. For this reason, the CoAct model does not describe a transactional workflow, as defined in [Weikum, 1993]. The transaction model by which the data operations are executed in CoAct is the open nested transaction model [Weikum and Scheck, 1991], which is a semantic transaction model [Weikum, 1993]. The semantics of the CoAct model has played an important role in the design of CoCoA.

The history merging mechanism provided by the CoAct transaction model has allowed us to take advantage of high-level system primitives in the definition and implementation of the CoCoA language. In related work, the ASSET transaction framework [Biliris et al., 1994] has identified a number of system-level primitives to support the definition of application-specific transaction models. It is shown how to use the primitives to model the relaxed correctness requirements found in cooperating transactions and workflows. It is assumed that the primitives are used in the code generated by a compiler; the issue of mapping a high-level specification language to these primitives is not addressed. In contrast, in the TRANSCOOP Project, we have concentrated on the development of high-level language features to describe cooperation in the context of a specific cooperative transaction model.

The ASSET primitives have recently been used in [Martin and Ramamritham, 1997] to synthesize delegation and the resulting history rewriting found in advanced transaction models. Our work also involves delegation, but we take a more fine-grained view with respect to the operations that are delegated. Delegations (exchanges) in the TRANSCOOP model are made by users (specified in terms of user roles) rather than by transactions as they are in ASSET. User-directed delegation provides more flexibility for the support of cooperative activities: multiple users can participate in a transaction, and a transaction boundary is not tied to a particular user. Another difference between our work and the ASSET approach is that delegation in the TRANSCOOP model is semantics-based, whereas in [Martin and Ramamritham, 1997] delegation is described in terms of a generic update operation on database objects.

During the first year of the TRANSCOOP Project, we investigated the use of the process algebraic specification language LOTOS [Bolognesi and Brinksma, 1987] to specify cooperative activities [Even et al., 1996b]. A drawback of this approach was the fact that distinct scenario concepts were all described by events. This lack of a linguistic distinction between different concepts proved difficult for the typical scenario specifier to understand and use. It was for this reason that we opted to design the more conceptual language CoCoA. Other formal techniques have been used to specify the semantic's of workflows: Aalst [van der Aalst, 1997] shows how Petri-nets can be used to verify properties of workflows, whereas [Ngu et al., 1994] is an example of a communication constraint formalism based on Propositional Temporal Logic [Manna and Pnueli, 1981]. With these formalisms, we see the potential for the same drawbacks that we experienced with LOTOS. It is also the case that some semantics issues are abstracted away in these approaches. For example, [van der Aalst, 1997] abstracts away from the computations done by the tasks in a workflow.


The MENTOR Project [Wodtke et al., 1996, Wodtke and Weikum, 1997] looks at the specification and execution of distributed workflows. The formalism is based on state and activity charts, which share similarities with the step definition facilities of CoCoA. A notable difference is that an activity in MENTOR is 'an arbitrary piece of C code' [Wodtke et al., 1996]. The main contribution of [Wodtke and Weikum, 1997] is a method for the behavior-preserving transformation of a centralized workflow specification into a distributed workflow specification. The MENTOR transformation assumes that the centralized state and activity chart is defined in such a way that orthogonal business units can be identified by the partitioning. The main distinction between the MENTOR approach and the model underlying the CoCoA language is that CoCoA addresses cooperation inside what would be a single business unit in the MENTOR approach. In contrast to our work, the formal model described in [Wodtke and Weikum, 1997] does not address the kinds of complex values found in object-oriented databases. In a distributed MENTOR workflow, variable updates done in different activities must be detected and collected (apparently as part of the C code) for communication to other activities to keep shared data consistent [Wodtke et al., 1996].

6.12 DISCUSSION

If we care to take a critical look at the language described in this chapter, we may observe that it features a number of useful cooperative primitives, but also some characteristics that are somewhat restrictive. In these sections, we look at some of the weaker sides of CoCoA. We do so from a standpoint of requirements for and expressiveness of the language.

Expressiveness is a well-studied phenomenon for formal languages such as programming languages, query languages and specification languages. CoCoA is, by its definition, a combination of process algebraic and typed functional ideas, and we are not aware of useful formal expressiveness results for such combined languages.

Essentially, CoCoA's novelty is just this combination of two formal paradigms, done for a specific application field of interest: cooperative transactions. This observation leads to a number of weaker points, if we judge CoCoA by either a process algebraic yardstick, or a functional yardstick alone. We review a number of these points.

6.12.1 Support for Process Aspects

Under this heading, we may look at the primitives supported for process definition, but also at the methodological issues that are or are not supported for the design of the processes.

Elementary process definition primitives include sequential composition, parallel composition and synchronization, process enabling and disabling, recursive process instantiation, and data communication. All of these are to


some extent supported in CoCoA's step notion and related interactions, but not always in the most general way.

Interactions and steps are primitive enough to allow sequential and parallel compositionsj a primitive synchronization mechanism is lacking, however. Asynchronous communication between two processes can be defined, but doing it is cumbersome, and it becomes more difficult when data should be communicated between different workspaces as part of the communication. This is actually common in cooperation that involves negotiation. Moreover, when more than two collaborators are involved in the communication, this will have to be resolved with binary, asynchronous steps. Furthermore, data communication as such is not part of CoCoA's primitivesj it can be done, but only via the elaborate way of using CoCoA's import/export facilities and a workspace.

Process enabling and disabling can also be 'hand-coded' in CoCoA. Since these operators are not truly abundant in cooperative process modeling (unless exception handling is a main issue), this hand-coding is not considered a serious drawback. Another issue is recursive process instantiation, which in a general form is absent in CoCoA. What CoCoA does offer is a specification form for instantiating countably many similar processes, each of which is uniquely identified. Formal expressiveness results for CoCoA's parallel steps are lacking, but if this construct has equivalent expressive power to arbitrary recursive process definitions, it remains to be shown what the practical relevance of this would-be equivalence is.

We may also focus on issues related to the support for a good design method with CoCoA. One may hold the view that cooperative processes are essentially of an asynchronous nature, but the rigidity of this point of view, as advocated by the current CoCoA, has unpleasant consequences. For instance, assuming the language would also accommodate synchronous communication primitives, it would allow to abstract away from the procedures underlying negotiations between collaborators, which would be described typically by intricate asynchronous communication patterns. Such a pattern could at a higher level be represented by a single synchronous communication. With this, we have identified an important methodological weakness of the language: the lack of support for refinement to aid in the design method. A refinement theory has not yet been developed, and is known to be far from trivial. (See for example related work on action refinement techniques for LOTOS [Rensink, 1993].)

6.12.2 Support for Functional Aspects

Looking at the computational power of the CoCoA language is, in fact, looking at that of its underlying functional database language, TM. Little extra is required here, since this latter language has been shown to offer a fairly complete set of features for the database schema designer. These include a query language that has OQL essentially as a sublanguagej it allows recursive function definition, and its language is strong enough for describing any required data manipulation down to the object level.


A criticism worth following up, and strongly related to the problem of nway synchronization between collaborators, is that of mutual data operation invocation. This feature is required in situations in which the actual parameters for a data operation invocation (or data exchange operation, for that matter) need to be provided by multiple collaborators. We investigated this issue in LOTOS/TM in [Even et al., 1996bJ. In some scenarios, the protocol may be strict on this, and will require that everyone delivers at the same time. Again, intricate hand-coding requiring multiple steps can be used to circumvent the problem, but we do not consider this an elegant solution.

In a formal study with the LOTOS and TM languages as basis, these types of synchronous interaction between collaborators in a scenario were seriously considered, as we thought of them as innovative ideas for the field of cooperative work. For unrelated reasons, this language combination turned out to be not the optimal choice for describing transactional workftows. Most importantly, the transaction concept requires events to be undone sometimes, and this is a characteristic that is not easily captured in process languages with trace-like semantics. One may state that process languages are event-based (every event has a meaning, and cannot be wiped out), and the CoAct transaction model also developed in the project was given a history-based model, in which the semantics of operations at any point in time is governed (in part) by what has already happened in the past. Matching the semantic models of processes and transactions was attempted, but reconciliating the two views was considered impossible without essential surgery on at least one of the two involved models.

6.12.3 Support for Application Requirements

A not to be ignored practical issue related to the process recursion problem discussed above, is the dynamic addition of collaborators to a scenario, which at present is not supported in CoCoA. Any collaborator must be made known at scenario instantiation time.

We restate that communications or operations that conceptually seem to require a multi-user technique, are currently also not supported in CoCoA. We find this not a grave omission, as such multi-user initiation can be described as a combination of unary initiations with binary process overhead, but the latter would at best be second-class citizens, would provide unwanted and unnecessary implementation detail, and would go against the elegance that is required for a good specification language.


Appendix: The CoCoA Syntax

Introduction

We provide here the syntax of the CoCoA language using rail diagrams, as supported by the CoCoA parser/type-checker. A CoCoA specification can be thought to exist of three parts. The first part provides the general definitions, which are used by the subsequent parts. The second part provides the specification of the organizational aspects of the scenario, and the third part gives the transactional aspects of the scenario.

General CoCoA Scenario

The syntax for a complete CoCoA scenario is provided below. For this diagram only, consecutive diagram lines should be read as constituting a single, consecutive diagram. CoCoA

cenanoName

l@i)O{operationsrr DataOperationSignature f11

L{llorkspace ~ WorkspaceTypeDef f11

l{cornmunications rr CommunicationOperDef f11

l@i)O{exChange)-{operationS>---CDataExchoperDefS"J

ProcedureDe

--~------------------------------rfend


A data operation is defined by its name and input parameter types: DataOperationSignature -1 DataOperName kD CD ~ lo1TMTypeExpr~

A workspace type is defined by enumerating the data operations it can contain: Workspace TypeDe/ -1 WorkspaceTYpeName ~ DataogrName F

A user type is identified by its name. It can have an optional data type, if it is used as an argument to a data operation. It can have an optional workspace type, which limits the data operations the user can do. U serTypeDe/ -1 UserTYpeName I

~ bata!ypeName ~ ~ WorkspaceTypeName ~ A communication primitive is defined by its name and input parameter

types: CommunicationPrimDe/ -1 CommPrimName kD t:::ITMTYPeEXPr CD--

~ A data exchange operation is defined as a select operation on a workspace:

OperationElem -1 OperationName H ExprOrAnyListPack f-EzprOr A nyListPack -{De@-Organizational Aspects

The organizational aspects of the scenario are given in the procedure definition, which also specifies the parameters for the users, and the interaction points of the top-level step:


ProcedureDe/

User;:;,L;:ris.::...t """TO"---' --r UserName ~MTYpeEXpr T PointLi8t

PointDe/

-IPolntN='I~ eEx r

W ork8paceDe/ ~w::O-o:-::r:;:k""Bp~a:-:c:-:-e}1 WorkspaceName ~ WorkspaceTYpeName ~

The body of a procedure consists of a list of step statements, each of which is either a step definition, a transition definition, a parallel clause or an enabling

The definition of step consists of a name with an enumeration of interaction points followed by a number of step statements: StepDe/ ~ StepName H Point List ~ StepStmt ~

A transition is defined by an expression specifying at which points it starts, and a list of points at which it ends: Tran8De/ ~"""n"""'o--'i-nt"" do AOiIlt ~~

OnPoint


YSt,pN_l~o-f ~ TMEx r

A parallel clause has a list of parameters, by which the instances are identified, and contains a list of step statements that define the instances:

An enabling expression states which operations are enabled after an incoming transition has occurred. Each enabling expression may enable a number of data operations, data exchange operations, and communications: EnableEzpr

;,..,o:Tm::-,t,....,,.,.....,..--::-:::::--=--

The enabling of a data operation is done by giving its name, and specifying the restrictions on the values of the parameters: EnDataOperation -l DataOperName H ExprOrAnyListPack f-

A data exchange operation can be used for importing and exporting operations between the workspace of the user and any of the other workspaces. The enabling of a data exchange operation is done by giving its name, specifying the restrictions on the values of the parameters, and stating the name of the workspace: EnDataEzchOper

nD~a:;:t7ar.;E=xch::;:-;'<::-::::r.;==--, '-="-=-~


DataEzchOperEzpr --l DataExchOperName H ExprOrAnyListPack ~

Communication operations are invoked by the users of the scenario, by giving the name of the operation and the values for the parameters. It is also possible to specify an additional condition that has to be met, in order for an interaction on a given point to occur: En CommOper

£ugs~e~r~N~a~m~e~==~~~~~~~~~~~~~----------------------~l ForParamName

The extended TM predicates contain two extra clauses not found in the TM predicates:

QueryEzpr ~riW"'o':':r""'k-:'sp--a:-:c-:'e"E--xp--r-'f-@1 ExecRuleName I ~

~~~

Transactional Aspects

The transactional view defines the execution rules, and the history rules. We first provide the syntax of the execution rules and the ordering expressions that are used in these rules: EzecRuleDe/

~ OrderExpr ~

y ExecRuleName ~ Y ForallClause ~ ForAliClau8e ...... __ ----.,...----.,

-@i!IDr"amNam.~,%:;~


Operation WithResult -1 OperationName HOE~X~p2.!r~O~r~A~n~Y1L~is~tfP~ac~k~If...l0:fV'----,--L]-r

-.:.... ~arIableT

The above syntax rules are a concise version of the real rules, which are:

We give the syntax of the history rules below; these rules define the commutativity relationships between operators:

NonCommClause noncommutative

TM Syntactic Symbols

In the above syntax, we have used a number of symbols that refer to nonterminals in the TM syntax [Bal et al., 1996]; these are the grammar symbols starting with the characters 'TM'.

7 THE TRANSCOOP TRANSACTION MODEL

Justus Klingemann

Thomas Tesch

Jjjrgen Wasch

Wolfgang Klas

7.1 INTRODUCTION

This chapter describes the TRANSCOOP cooperative transaction model COACT, and its underlying paradigm of cooperative work. As motivated in Chapter 4 new application areas of the transaction concept impose new requirements on transaction models. In all of the discussed application areas there is a need to support the cooperation of human actors engaged in common tasks and working towards a common goal. A transaction model supporting cooperation should make the sharing and exchange of information among co-workers as natural as possible while still preserving a notion of consistency.

In general, transactions in cooperative environments need to support the interactive processing of activities of long, uncertain duration, in which the competition for resources is replaced by the need to cooperate. The emphasis, therefore, is not on preventing access to resources (like in a serial world), but rather on the interoperation, i.e., the semantically correct exchange of information, among concurrent activities of cooperating, possibly geographically distributed or mobile, users. In such environments, failure atomicity may be too strict, and isolation among concurrent users contradicts the need of coop-

149




eration. Hence, we need to replace these criteria by new ones which are more suitable for cooperative applications.

The COACT model supports alternating periods of individual and joint work, and allows to exchange results consistently. In order to achieve this, we take a behavior-oriented view rather than a state-oriented view: the consistency of common work results is determined, based on the semantics of the operations performed to obtain these results. The necessary fundamentals are introduced in Section 7.2.

To specify cooperative scenarios in TRANSCOOP, the specification language CoCoA (see Chapter 6) allows the description of organizational and transactional aspects of a cooperative scenario, using CoCoA's declarative language constructs that extend a given database schema. A cooperative scenario in COACT is described by a Cooperative Activity Type which corresponds to the transactional part of a CoCoA specification. All details about Cooperative Activity Types and its constituents are given in Section 7.3.

The TRANSCOOP demonstrator system uses the SEPIA authoring system as demonstrator application. Therefore, throughout this Chapter, we use a running example motivated by the SEPIA application in order to illustrate the transaction model concepts. The example is introduced in Section 7.4.

The behavior based approach to achieve cooperation taken in COACT is introducing the paradigm of merging histories of different workspaces. The model utilizes semantics-based transaction management concepts to relax the isolation property of traditional transaction models. Semantics-based transaction processing techniques seem to be a promising approach to overcome concurrency limitations of traditional transaction models [Schwarz and Spector, 1984, Weihl, 1988, Farrang and Ozsu, 1989, Weikum and Schek, 1992, Muth et al., 1993, Walborn and Chrysanthis, 1995]. These techniques exploit either the semantics of methods defined on objects (data-oriented approach), or the semantics of transactions (transaction-oriented approach) [Skarra and Zdonik, 1989] to enhance concurrency in object-oriented database management systems (OODBMS). We present a formal treatment of COACT'S semantics-based transaction management concepts. COACT utilizes both backward and forward commutativity [Weihl, 1988] relations to develop a correctness criterion for the exchange of information among co-workers. All details on the underlying execution model are presented in Section 7.5. A concluding summary discussing the applicability of the model is presented in Section 7.7.

7.2 OVERVIEW OF THE COACT MODEL

In general, cooperative work is characterized by alternating periods of individual and joint work (see Chapters 4 and [Kaiser, 1995]). During individual work periods, users tryout alternative problem solutions while co-workers may work simultaneously on the same subject. Access to and use of shared data should neither block other users nor should it affect co-workers unintendedly. During joint work, co-workers should be able to exchange information and to

THE TRANSCOOP TRANSACTION MODEL 151

Common WorkSpace co

delegate

Figure 7.1 Workspaces and exchange facilities in COACT

share final as well as intermediate results. Co-workers should be able to form subgroups of cooperating actors dynamically. Joining and leaving an ongoing cooperative effort should be possible.

Therefore, we assign in COACT a private workspace to every user who takes part in a collaborative effort (cooperative activity). By default, the private workspaces of the co-workers are isolated from each other and can only be accessed by the workspace owner. Additionally, there exists a common workspace per cooperative activity. The common workspace is isolated from the private works paces and is not assigned to a single actor in a cooperative activity. The common workspace contains the data items available when a cooperative activity is started and the results of the cooperative activity when committed. Figure 7.1 gives an overview of the constituents of the COACT model.

To achieve isolation of workspaces, we (conceptually) copy the data items initially contained in the common workspace to all private workspaces. From these copies the actors can create throughout the working process their private versions of data items that can be manipulated independently. Hence, modifications to data items done by different co-workers do not interfere. For each workspace, we keep a log of the modifications in a workspace history.

To model the correct interaction, i.e., cooperation, of users involved in a cooperative activity, we introduce the concept of cooperative activity types (CAT). Each cooperative activity is specified by a single CAT.

First, a CAT describes a set of data operation types. The users invoke these operation types in their own private workspaces. The invocation of the defined data operation types is the only means to change the workspace state. The resulting data operation instances (sometimes also called data operation executions) appear as atomic state changes on the respective workspace state. The workspace history is a sequence of data operation instances. Each history entry contains all information about the respective operation instance. As long as it is clear from the context, we found it convenient to use the term operation to denote both, data operation types, and data operation instances.


Second, a CAT describes a set of merging rules that exploit the semantics of operations to guide the process of information exchange (history merging).

Exchange of information among workspaces is an explicit act that is initiated by an actor through invoking one of COACT'S exchange operations. The exchange operations are generic meta operations of the COACT model (like starting, aborting, or committing of a cooperative activity) and are all based on the paradigm of merging workspace histories. Three exchange operations are defined in the model, namely import, delegate, and save, in order to realize different options for exchanging information:

1. Co-workers can directly exchange working results between their private workspaces by means of import and delegate. Import is used to incorporate operations executed in the scope of another workspace into the own workspace. The importing user is responsible for resolving conflicts that may occur during the merge. Delegate is used to pass on a set of operations to a co-worker who is then responsible for merging them into his own workspace.

2. Co-workers can exchange working results through the common workspace by means of the save and import. An actor can use save to incorporate operations of his workspace into the common workspace, thus, making (parts of) his results public to all co-workers. The user who invokes the save is responsible for the resolution of conflicts. Other co-workers can retrieve this information using the import described above.

The merge mechanism allows only to exchange consistent parts of workspaces. A consistent part of the workspace state is in COACTS behavior based approach represented by a consistent unit of work which is a sequence of operations. We identify such consistent units of work by examining the backward commutativity relation [Weihl, 1988] between operations contained in a workspace history. The incorporation of operations in another workspace is then realized by their re-execution in the respective destination workspace. The semantic correctness of the exchange of operations is guaranteed by ensuring that the re-execution of an operation has a "view" on the history in the destination workspace equivalent to that in the source workspace. Hence, the behavior of operations during re-execution in terms of output parameter values is indistinguishable from the initial execution. We use the forward commutativity relation [Weihl, 1988] to check this. If the merge process cannot be performed without violating the semantical correctness, the merger offers different alternatives how to proceed. In this case, the controlling user can select a consistent sequence of operations.

If an operation has been successfully incorporated into another workspace, it is conceptually the same operation which is present in more than one workspace. The presence of identical operations in several workspaces enables us to establish a close cooperation between co-workers. The degree of cooperation is scalable depending on the exchange frequency.

Those parts of a cooperative activity that are reflected in the common workspace after its completion (commit) are considered as the final result. It is

THE TRANS COOP TRANSACTION MODEL 153

assumed that all users integrate their relevant contributions into the common workspace such that there is a single result of the cooperative activity.

7.3 COOPERATIVE ACTIVITIES

We describe here formally the constituents of a cooperative activity type which are important for the understanding of the transaction model. Note, in the TRANSCOOP system, a cooperative activity type is generated from a CoCoA specification as illustrated in Section 8.4.4.

A cooperative activity is defined by a cooperative activity type CAT = (name, 0, M) where

• name is the name of the CAT,

• 0 is a set of operation types defined on each workspace,

• and M is a set of merging rules.

In the remainder of this section, the specification of operations and merging rules are described in detail.

7.3.1 Operations

The set 0 defines a finite set of (data) operation types. The actors of the cooperative activity invoke these operation types in their workspaces. Operations appear as atomic state changes on the respective workspace and are executed, in contrast to the cooperative activity, under the control of a single actor. With ~ we denote the (possible infinite) set of all data operation instances of O.

To enable the exchange of operations we require that the specified operation types are deterministic functions and guarantee termination. We further require that for all operations a compensating operation is specified. The compensating operation is semantically undoing effects of the original operation rather than physically restoring the prior workspace state [Korth et al., 1990, Nodine and Zdonik, 1996]. It is the scenario designer's responsibility to specify the compensating operation. Formally, compensation is specified by a function camp : ~ -+ ~ such that comp(a) = acomp. Compensation is further described in Section 7.5.7.

To let users act autonomously within their workspaces, we compensate operations only within a single workspace, i.e., if an operation is compensated it is not discarded in all workspaces in which it occurs.

7.3.2 Merging Rules

The merging rules are needed to allow for a semantically correct exchange of operations among workspaces. The merging rules consist of the backward commutativity relation (bc) and the forward commutativity relation (Ie) [Weihl, 1988, Lynch et al., 1994] defined over data operations in ~.


The specification of the relations be and Ie provides for each pair of data operation types a predicate involving their parameters. By applying the specified predicates to the respective operation instances, the membership in the be or Ie relation, respectively, can be easily checked at run-time. This specification concept corresponds to commutativity tables as introduced in [Beeri et al., 1983, Korth, 1983, Schwarz and Spector, 1984]. Note, that the evaluation of the predicate depends only on those parts of the workspace state reflected in the parameters. The exact semantics of both relations is defined in Sections 7.5.5 and 7.5.9, respectively.

7.4 RUNNING EXAMPLE

In order to illustrate the history merging functionality of COACT we introduce a running example that is used throughout this Chapter. The example is motivated by the cooperative hypermedia authoring system SEPIA [Streitz et al., 1992], which has also been selected for the TRANSCOOP demonstrator system[de By et al., 1996] (see Chapter 8).

SEPIA (Structured Elicitation and Presentation of Ideas for Authoring) supports different activities of the authoring process, i.e., planning, content acquisition and structuring, and preparation of the final document. In contrast to traditional linear hierarchical structured documents, the concept of hypertext allows to have network-like document structures. SEPIA documents consist of nodes and connecting links which enable authors to create and present associative reference structures between information entities.

Because we treat the authoring process from a database point of view, we assume a scenario in which multiple authors are manipulating a collection of shared hypermedia documents that are stored in a database management system. The SEPIA hierarchical hypertext document structure and the corresponding operations for the creation and manipulation of SEPIA document structures are modeled explicitly in the database schema [Wasch and Aberer, 1995, Bapat et al., 1996b]. We shortly introduce the data operations 0 provided by SEPIA that are used in the example:

• createNode(IN: NType, Name, OUT: Node) creates a new node where NType specifies the type of hypertext node, e.g., a contentNode representing document content, Issue for a problem to be solved, or Position standing for an an authors position. (For a complete list of node types see [Streitz et al., 1989, Wasch and Aberer, 1995].) The identifier of the new node is returned.

• addContent(IN: Node, Content) adds content to a node where Content can refer to arbitrary media like text, audio or video.

• createLink(IN: LType, Node, Node, OUT: Link) creates a link between the specified nodes. The type of the link is determined by Ltype, e.g., two content nodes can be linked by a RefersTo link. The identifier of the new link is returned.


• deleteNode(IN: Node, OUT: NType, Name) deletes the specified node and returns the node type and the name of the deleted node. If a link is referring to the node to be deleted, the node is not deleted. This avoids dangling links.

• deleteLink(IN: Link, OUT: LType, Node, Node) deletes the specified link and returns the nodes and the link type.

Further parts of the CAT specification will be presented in the next section, when their concepts are formally defined.

7.5 A FORMAL MODEL OF HISTORY MERGING

In the following, we define the basic building blocks of our model that allow us, in the remainder of this section, to derive our notion of correctness.

7.5.1 States

Let E be the set of all data items that can occur in a workspace. Let dom(e) denote for each data item e E E its domain. Then, a state 5 is a mapping that assigns to each e E E a corresponding value from dom( e) U {.l}. If 5 denotes the state of a workspace ws, we define e E ws :? 5(e) "I .1. With 51. we denote the empty state, i.e., '<Ie E E : 5(e) = .1.

7.5.2 Operations

We model an operation instance op E ~ as a tuple (id, t, I, 0) consisting of

1. a unique identifier id,

2. the corresponding operation type t,

3. a set of actual input parameters I,

4. a set of actual output parameters O.

To refer to the different elements of an operation, we write op.component, e.g., op.t to refer to the corresponding type.

The unique identifier id is needed to identify 'identical operations' that occur in more than one workspace. This is not possible via parameters only. The scope of uniqueness is the corresponding cooperative activity, i.e., if operations are exchanged among workspaces their unique identifier remains untouched such that it denotes the initial (first) execution although it is re-executed in the destination workspace.

The parameters can either contain data items from the workspace state or values provided by the invoking user. Note, an operation is allowed to access additional data items not reflected in its signature.

Output parameters are enclosed in our concept of operations, too. Hence, an operation models not only an invocation but also its corresponding response


event [Weihl, 1988]. Therefore, we first have to define whether invocation and response match for a certain state. This is captured by our notion of legal operations.

Definition 1 (legal operation) An operation op = (id, t, I, 0) is legal in a state S iff op.t applied to state S with input parameters op.I yields output parameters op.O.

7.5.3 Histories

A history h = (OP, «op) is a finite set OP ~ E of operations together with a total order «op over OP reflecting the execution order. For simplicity, we denote a history h = (OP,«op) as [al, ... ,an] iff OP = {al, ... ,an} 1\

(ai,aj) E«op¢> i < j. Such sequences can be concatenated, i.e., [al, ... ,ai, aj, ... ,an] = [al, ... ai]. [aj, ... ,an]. Next, we extend the notion of legal operations to legal histories by applying the above definition to finite operation sequences.

Definition 2 (legal history) A history [ab . .. , an] is legal for a state S iff there is a sequence of states So, .. . , Sn-l with S = So, ai legal in Si-l, and Si results from the execution of ai in state Si-l for i = 1, ... , n. We say a history is legal if it is legal for state 8.L.

With Sn = [al, ... , an](So) we refer to the state Sn resulting from the execution of the sequence [al,' .. , an] in state So. The notion of legal histories allows us to define the equivalence of states. Two states are equivalent if they are not distinguishable for all subsequent operations.

Definition 3 (equivalent state) Two states 8 and 8' are equivalent (8 == S') iff

V histories h: h(S) legal ¢> h(S') legal

With hI == h2 we refer to hl(S.L) == h2(8.L).

A history h' is a subhistory of a history h if it contains only a subset of the operations in h and if the operations in h' obey the execution order of h.

Definition 4 (subhistory) A history h' = (OP', «oP') is a subhistory of h = (OP, «op) iff

OP' ~ OP 1\

Va',b' E Op': (a',b') E«op¢> (a',b') E«op'

7.5.4 Workspace Histories

A cooperative activity CA is a set of histories representing the workspaces with an identical initial workspace state Sinit. Therefore, we write CA = (Sin it, { WSo, WSI, ... , WSn}). The work of a single user within the scope of


a cooperative activity is modeled as a workspace history. The workspace WSo denotes the common workspace of the cooperative activity. In practise, the number of workspaces can change dynamically as participants join or leave the cooperative activity.

Conceptually, the state Sinit is copied to each workspace in order to achieve isolation of executions in different workspaces, e.g., by a dynamic replication scheme. Hence, operations can be executed independently in different workspaces. To ensure that subsequent definitions are independent of Sinit, we require :3 history h: h(S.l) = Sinit.

7.5.5 Dependencies Within a Single History

So far we have explained how the work in each workspace is modeled by the concept of legal histories. Now, we will describe how operations can be exchanged among workspaces. First of all, we introduce the central concept of consistent units of work. It allows us to determine dynamically consistent parts of workspace histories that can be exchanged among workspaces.

An operations might depend on previously executed operations, i.e., its behavior is influenced by these operations. Hence, we may not be able to exchange a single operation but have to take care that all operations it depends on are exchanged, too. By identifying all relevant predecessors of a given operation, we are able to identify consistent units of work that can be subject of an information exchange.

Since we are interested here in determining dependencies within single workspaces, we need a dependency relation that is based on update-in-place policy. Therefore, we apply the backward commutativity relation be [Weihl, 1988]. The bc relation can be informally described as follows: two operations a and b commute backward if, for all workspace states in which a can be executed directly after b or vice versa, the execution order can be exchanged without affecting the output values of a and b, and without affecting any subsequent operation. Note that the relation is symmetric but not transitive.

Definition 5 (backward commutativity relation) We introduce the backward commutativity relation be which is defined over ~ x ~:

'ia,b E ~: 'i histories h

(a, b) E be :¢>

(1) h - [a]- [b]legal ¢> h - [b]- [a] legal (2) h - [a]- [b] == h - [b]- [a]

The conflict specification using backward commutativity for the example in Section 7.4 is given in Table 7.1. If the conflict predicate evaluates to true the two operations do not commute backward.

The relation be is used to define certain properties on histories that allow us to describe consistent units of work.


Table 7.1 Backward commutativity: specification of conflicts

Operation pair

createNode{IN: NType, Name, OUT: Nodel) addContent{IN: Node2, Content) createNode{IN: NType, Name, OUT: Node) createLink{IN: LType, srcNode, dstNode, OUT: Link) createNode{IN: NTypel, Namel, OUT: Node) deleteNode{IN: delNode, OUT: NType2, Name2) addContent{IN: Nodel, Contentl) addContent{IN: Node2, Content2) addContent{IN: Node, Content) deleteNode{IN: delNode, OUT: NType, Name) createLink{IN: LType, srcNode, dstNode, OUT: Link) deleteNode{IN: Node, OUT: NType, Name) createLink{IN: LTypel, srcNodel, dstNodel, OUT: Link) deleteLink{IN: delLink, OUT: LType2, srcNode2, dstNode2) deleteNode{IN: Node, OUT: NType, Name) deleteLink{IN: delLink, OUT: LType, srcNode, dstNode)

Definition 6 (closed subhistory) A subhistory h' tory h = (OP, «op) is closed iff

Conflict predicate

Nodel = Node2

Node = srcNode OR Node = dstNode

del Node = Node

Nodel = Node2 AND Content! i- Content2

Node = de/Node

Node = srcNode OR Node = dstN ode

Link = delLink

Node = srcNode OR Node = dstN ode

(OP',«op,) of his-

'Va E OP, a' E OP', (a, a') E«op: (a, a') (/. be => a E OP'

A closed subhistory contains for each operation every earlier operation it depends on. We consider a closed subhistory as a consistent unit of work.

Theorem 1 Each closed subhistory of a legal history is legal.

Proof Sketch. By a simple induction we can show that each operation that is not part of the closed subhistory can be removed with the resulting history remaining legal. The induction step is as follows: Consider the last operation that is not part of the closed subhistory. Then, by definition of a closed subhistory, we know that it commutes backward with all subsequent operations. Hence, we can move it to the end of the history and thus it can be omitted. 0

Definition 7 (minimal closed subhistory) A closed subhistory h' = (0 P' , «op') of h = (OP, «op) is minimal under A ~ OP iff

'Va' E Op': (a' E A) V (3b' E Op': (a',b') E«op' /\(a',b') (/. be)


Workspace A

AI createNode(ln: Content ......... Out: Nt)

A2 createNode(ln: Content ......... Out: N2)

I A3 createNode(ln: Position ......... Out: N3)

A4 createUnk(ln: RefersTo. Nt. N2. Out: Lt)

AS addContent(ln: Nt ........ )

consistent unit of work under A4 and A5

I A I createNode(ln: Content ......... Out: Nt)

I A2 createNode(ln: Content ......... Out: N2)

I A4 createLink(ln: RefersTo. Nt. N2. Out: Lt)

I AS addContent(ln: Nt ........ )

Figure 7.2 Computation of consistent unit of work with be

A history is minimal closed under A iff it contains only operations of A or those, operations of A (possibly transitively) depend on.

Definition 8 (independent subhistories) Two sub histories h' = (0 P' , «oP')' h" = (OP", «oP" ) of h = (OP, «op) are independent subhistories iff

OP' n OP" = 0 /\ '<la' E OP', a" E OP": (a',a") E be

Two subhistories are independent if they contain disjoint sets of operations and there are no relevant dependencies between them. Two independent closed subhistories correspond to consistent units of work that can be exchanged independently.

7.5.6 Example: Consistent Units of Work

Figure 7.2 shows the workspace history of workspace A of a cooperative authoring activity as introduced earlier. Each box represents an operation that has been executed by the user controlling workspace A. In order to identify consistent units of work, the user selects a subset of the operations in his workspace history. Then, according to Definition 6, the system selects recursively the non-backward commuting predecessor operations of the workspace history HA. Assuming the user selects operations S = {A4' As}, the minimal closed subhistory of H A under S is [AI, A2 , A4, As]. The creation of the link L 1 connecting the nodes N1 and N2 represented by operation A4 depends on the creation of the nodes by operations Al and A2 • Operation As which adds content to node N1 depends on Al which created the node. The dependencies are based on the be relation introduced in Section 7.4. The non-backward commutative predecessors are visualized by arrows in Figure 7.2.

7.5.7 Compensation

To allow for the interactive exploration of different problem solution strategies that are carried out within the private workspaces, we require recovery services


that allow to retract decisions taken by a single actor (by the compensation of operations) .

Definition 9 (compensation) The compensation function eomp given in the specification is defined as follows:

Va, acomp E :E : eomp(a) = acomp :¢:}

V history h: h - [aJ is legal => h - [aJ- [aComPJ is legal /\. h == h - [aJ- [aComPJ

For example a ereateNode operation is compensated by a deleteNode, i.e., eomp(ereateNode(IN: NType, Name, OUT: Node}) = deleteNode(IN: Node, OUT: NType, Name}

The interpretation of Definition 9 is that the execution of acomp immediately after a is simply the undo of a. This means that no subsequent operation can observe that the sequence [aJ - [aComp) is part of the history. Note, that it is sufficient for the resulting state to be equivalent to the state that would have been reached if the compensated-for operation would never have been executed, i.e., the states need not be identical [Korth et al., 1990).

Compensation becomes more difficult if we want to compensate an operation a in case further operations have been performed, yet. It may be the case that these subsequent operations are dependent on the results of a such that a cannot be compensated without affecting its successors.

Definition 10 (compensatable) An operation a of a history h = (OP, «op) is compensatable iff

h - [aComp) is legal/\. => (b, aComp ) E beVb E OP : (a, b) E«op=> (a, b) E be

If a is compensatable in a history h we can directly apply the compensation. Otherwise, we have to compensate all operations b with (a, b) E«op and (a, b) f/. be to correctly compensate a. This ensures that compensation does not disturb the outcome of dependent operations.

7.5.8 Example: Compensation

Assume the user of workspace A has performed the operations shown on the left side of Figure 7.3. If the user decides after the execution of As to compensate the creation of node N1 represented by operation Al , it is checked whether Al is compensatable. Due to the fact that (Al , As) f/. be, the system first compensates As, i.e., the node N1 cannot be deleted as long it is connected by link Ll. Operation As is compensatable, thus, the compensation A; can be directly applied. Afterwards, the node N1 can be deleted by executing the compensation operation A~. Note, the resulting history [Al,A2,As,A~,A~) is equivalent to the history [A2J not containing the compensating operation pairs. This is illustrated on the right part of Figure 7.3. Therefore, during the computation of consistent units of work and during the computation of the merge, compensating operation pairs are ignored because they have no effect on the workspace state.


Workspace A Workspace A

I AI createNode(ln: Content, " ... n, Qut: N1) :-..1 1- -creiiteNode(I~: CO~;en-t,-'~.~'\ O~t~ Nil ----: ------------------ - ----------------I A2 createNode(ln: Content, " ... ", Qut: N2) I A2 createNode(ln: Content, " ... n, Qut: N2)

I AS createUnk(ln: RefersTo, N1, N2, Qut: L1) [~~ ~ ~~~~~~~n~I~~ ~~!~r~!~~ ~~ ~ ~~~ ~~~:~~1} ~~: [~(~~~~~3} ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~ ~ ~ ~ J i.~!:.-_~~~~!~.iL:.·_·.·:.·.·_·_-_-_·_·_-:_-_-_-_·_-_·_._-.-.-.. _-.... _ .. J

Figure 7.3 (ompensatable operations and their compensation

7.5.9 Merging of Histories

The be relation introduced above allows us to identify consistent units of work that can be subject of an information exchange. If such a unit of work represented by a closed subhistory of a workspace history, is incorporated into another workspace history, we have to ensure that the exchanged operations behave in the destination history as in the source history.

Since we are here interested in determining dependencies between different workspaces, we need a dependency relation that is based on deferred update policy. Therefore, we apply the forward commutativity relation fc [Weihl, 1988]. The fc relation can be informally described as follows: two operations a and b commute forward if, for all workspace states in which a as well as b can be executed, they can be executed successively in arbitrary order without affecting the output values of a and b, and without affecting any subsequent operation. Note that the relation is symmetric but not transitive.

Definition 11 (forward commutativity relation) We introduce the forward commutativity relation fc which is defined over ~ x ~:

Va,b E ~: V histories h :

(a, b) E fc :¢:>

h - [a]legal/\ h - [b]legal => (1) h - [a]- [b]legal/\ h - [b]- [a] legal (2) h - [aJ- [bJ == h - [bJ- [aJ

The conflict specification using forward commutativity for the example in Section 7.4 is given in Table 7.2.

We call two histories W 8', W 8" E C A mergeable iff both histories are legal. Since both W 8' and W 8" belong to the same cooperative activity, they are both executions of the same cooperative activity type. Additionally, it is guaranteed that all W 8 i E C A are based on the same initial workspace state 8init .

A merged history M = (0 PM, «OPM) is constructed out of two mergeable histories W8' = (OP', «op.), and W8" = (OP", «op,,). In the following we use W 8 = (OP, «op) to refer to one of the two workspaces W 8' or W 8" to avoid symmetric conditions. We use Ws and W 8 to refer to different histories of {W8', W8"}.


Table 7.2 Forward commutativity: specification of conflicts

Operation pair

addContent{IN: Nodel, Contentl} addContent{IN: Node2, Content2} addContent{IN: Node, Content} deleteNode{IN: delNode, OUT: NType, Name} createLink{IN: LType, srcNode, dstNode, OUT: Link} deleteNode{IN: delNode, OUT: NType, Name} deleteNode{IN: delNodel, OUT: NTypel, Namel} deleteNode{IN: delNode2, OUT: NType2, Name2} deleteLink{IN: delLinkl, OUT: LTypel, srcNodel, dstNodel} deleteLink{IN: delLink2, OUT: LType2, srcNode2, dstNode2}

Conflict predicate

Nodel = Node2

Node = delNode

delNode = srcNode OR delNode = dstNode

delNodel = deiNode2

delLinkl = deiLink2

Definition 12 (correct merged history) We call M a correct merged history iff

1. OPM £;;; OPUOF

2. Va, bE OP : b E OPM /\ (a, b) E«op /\(a, b) rt bc => a E OPM

3. Va, bE OP : (a, b) E«op /\(a, b) rt bc /\ a, bE OPM => (a, b) E«OPM

4. Va E (OP \ OF), Va' E (OF \ OP) : (a, a') rt Ie => a rt OPM Va' rt OPM

First, we state that the merged history can only be constructed out of operations from the two input histories W S' and W S". Second, it is expressed that all relevant predecessor operations of any operation that is part of the merged history have to be included in the merge, too. Third, we require that a relevant ordering of operations in a source history is preserved in the merged history. Fourth, if two operations a and a' are not contained in both histories with a not forward commuting with a', only one of them can be part of the merged history.

Theorem 2 A correct merged history is legal.

Proof Sketch. From properties (2) and (3) we can deduce that the subhistory of M consisting of operations of OP is equivalent to a closed sub history of W S in the sense that it differs only in the order of operations that commute backward. Hence, by Theorem 1 it is legal. Property (4) guarantees that the history remains legal if operations from both histories interleave. The fact that property (1) ensures that there cannot be any further operations finally provides us with the theorem. 0


7.5.10 Merge Algorithm

In the following we describe the merging of operations from workspace history W8' = (OP',«op,) into workspace history W8 = (OP,«op). Note, the resulting history of the merge process as well as all intermediate histories that are constructed during the merge process are also denoted by W8. The merge process is performed in five steps:

1. Selection of operations from the source history W 8' by the user

2. Compute closed subhistory (exchange history)

3. Partitioning of exchange history into the maximal number of independent closed subhistories

4. Selection of operations from partitions along their dependencies

5. Merging of selected operations into destination history

As a first step, the controlling user selects a set I ~ OP' of operations to be merged into W 8. The operations in I do not necessarily comprise a consistent unit of work. To satisfy property (2) of correct merged histories, we construct the minimal closed subhistory P = (OPp, «oPp) under I. The subhistory P is the part of W 8' to be merged into W 8, thus, we call it the exchange history.

During the merge, there may occur conflicts between operations of W 8 and P. If we allow only an atomic merge of Pinto W 8, i.e., to include all or no operations of P, in case of a conflict we either have to discard a large portion of W 8 or we cannot include any operation of P at all. To minimize the loss of work during the merge process, we therefore allow for a partial merge, i.e., to include only parts of Pinto W8.

Hence, we partition P into independent closed sub histories (PI,"" Pk ).

Each Pi = (OPi , «op.) can be merged separately into W8. Note, that each OPi contains at least one a E I.

With bec we denote the complement of be. The fact that the relations bec n «Pi are asymmetric can be used to achieve an even finer merge granularity. Hence, we can merge each subset of OPi corresponding to a closed subhistory of Pi. Thus, we can include a E OPi into the destination history W 8 if all other members of the minimal closed subhistory of Pi under {a} are already included in W 8. To illustrate our approach, we introduce the -< relation:

Definition 13 We define the relation -<Pi for each Pi as follows:

Va, bE OPi : (a, b) E-<Pi:¢:> (a, b) E«Pi I\(a, b) ~ be

Given a partition Pi with its corresponding relation -<Pi' we start merging with an element a of history Pi that does not depend on any other preceding operation in Pi, i.e., Vb E OPi : (b, a) ~-<Pi' Afterwards, we can merge operations


from history Pi that are only dependent on operations already included in the merged history W S.

Formally, to fulfill property (2) and (3) when merging an operation a from Pi into W S, we require:

Condition 1

'Vb E OPi : (b, a) E-(Pi =} b E OP

To check whether the inclusion of a E OP' into history WS = (OP,«op) is in line with property (4) of correct merged histories, we require:

Condition 2

'Vb E OP \ OP' : (a, b) E fc

This condition ensures that operation a can only be appended to W S if it commutes forward with all operations in OP that are not in OP'. Since we deduced Conditions 1 and 2 are straightforward from Definition 12, the algorithm obviously constructs a correct merged history.

If Condition 2 is not fulfilled there are two possibilities how to proceed. First, the user can decide to abandon the inclusion of a into the merged history. This implies that we also have to abandon the inclusion of all remaining operations a' in Pi that depend on a, Le., (a, a') E-(Pi' Second, the operations in OP that are not forward commuting with a can be compensated. In this case it is possible to include further operations from Pi.

When all partitions Pi are processed by the merger, the algorithm terminates. However, this does not imply that all a E I have been incorporated into W S since the controlling user might have decided during the merge process to leave out some operations of I.

Note, that this algorithm is only used to determine which operations have to be compensated and which operations have to be re-executed. The actual execution of these operations is performed in a second step after all decisions have been made. First, all compensations are performed and afterwards the imported operations are re-executed. This separation of "logical" merge and the actual execution of operations avoids possible conflicts between compensating operations and re-executed operations which may result from the difference of backward and forward commutativity.

7.5.11 Example: Merging Histories

For our example, we assume two cooperating authors acting in works paces A and B. In this example the work starts with an empty document. This empty document represents the initial state of both workspaces.

Delegation from Workspace A to Workspace B. The user of workspace A performs the operations HA = [A 1 ,A2 ,A3 ,A4 l as shown in the left part of Figure 7.4. After the creation of content and position nodes (A 1 ,A2 ,A3 ), the


Workspace A Workspace B

AI createNode(ln: Content, " ... ", Out: N1) I A I createNode(ln: Content, " ... ", Out: N1)

A2 createNode(ln: Content, " ... ", Out: N2) I A2 createNode(ln: Content, " ... ", Out: N2)

I AS createNode(ln: Position, " ... ", Out: N3) I A4 createLink(ln: RefersTo, N1, N2, Out: L 1)

A4 createLink(ln: RefersTo, N1, N2, Out: L1)

Figure 7.4 Delegation from workspace A to workspace B

content nodes are connected by a link (A4). The user decides to delegate the link L1 to workspace B in order to stimulate contributions from his co-worker. For the selection I = {A4}, the minimal closed subhistory of HA under I is computed resulting in the exchange history E = [AI, A2 , A4l. This history is a consistent unit of work. The exchange history is send to workspace B where the user responsible for this workspace controls the integration of E into workspace B. The exchange history E contains a single independent closed subhistory and, thus, it cannot be further partioned. The merge algorithm starts now to integrate the operations of E into workspace B. First, forward commutativity conflicts between the operations of workspace history HE and the operations in E are computed. Due to the fact, that HE = 0, no conflicts occur. Therefore, the user of workspace B can integrate all operations of E. To perform the actual integration, the operations in E are sequentially reexecuted in workspace B. The resulting histories of workspaces A and Bare shown in Figure 7.4. Note, the re-executed operations are "replicated" among the workspaces A and B.

Import from Workspace B into Workspace A. Let us assume both users have continued in isolation resulting in the workspace histories presented in Figure 7.5. The user of workspace A has added by means of operation A5 some content to the node N1 which can be a descriptive text further explaining the authors intentions behind this node. At the same time, the user of workspace B has put his own description to his version of node N1 (Bd. In the remainder the user of workspace A has deleted link L1 as well as node N2 because they did not fit with his plans while user B has created a new content node N4 which is linked to N2. Both users have now changed the document content in conflicting ways, and we will now explore different merge alternatives.

User A plans to import the results of his co-worker and looks up the workspace history of workspace B. He selects operations 1= {BI, B3 } and calculates the merge alternatives. The merge algorithm computes the exchange history E = [AI, A2 , BI, B 2 , B3l. The exchange history E contains two minimal closed subhistories and can be partioned in PI = [AI, Bil and P2 = [A2' B2, B3l which



IAI createNode(ln: Content, " ... ", Out: Nt) AI createNode(ln: Content, " ... ", Out: Nt)

IA2 createNode(in: Content, " ... ", Out: N2) A2 createNode(ln: Content, " ... ", Out: N2)

IA3 createNode(ln: Position, " ... ", Out: N3) IA4 createLink(ln: RefersTo, Nt, N2, Out: Lt)

IA4 createLink(ln: RefersTo, Nt, N2, Out: Lt) 81 addContent(ln: Nt, " .. .'1

IA5 addContent(ln: Nt, " ... ") 82 createNode(ln: Content, " .. .", Out: N4)

IA6 deleteLink(ln: L t, Out: RefersTo, Nt, N2) 83 createLink(ln: RefersTo, N4, N2, Out: L2)

IA7 deleteNode(ln: N2, Out: Content, " .. .")

Figure 7.5 Before import from workspace B into workspace A

are merged separately in order to increase the flexibility during the integration process. For partition PI, operation Al is already present in history HA. According to Definition 12, no forward commutativity checking is required. Operation BI is processed next from Pl. It is not forward commutative with A5 and, thus, the controlling user has to select either to compensate A5 or to abandon the integration of B I . In our example, the user sticks to A5 and continues with the integration of P2 • First, A2 is already reflected in workspace A and can be ignored. Second, B2 does not conflict with the operations in HA and can therefore be merged with HA. Third, the integration of B3 connecting nodes N2 and N4 conflicts with A7 representing the deletion of N2. Again, the controlling user has the choice between compensating A7 in order to get B3 or to abandon the integration of B3 • We assume that the decision is to compensate A7 which results in the computation of the compensating operation A~ according to the compensation rules illustrated in Section 7.5.7. Afterwards, B3 can be re-executed in workspace A resulting in the history on the left side of Figure 7.6.

7.6 DISCUSSION OF OTHER RELATIONS IN THE CONTEXT OF COACT

In the previous sections, we argued for the use of backward and forward commutativity to determine dependencies between operations because they are based on update-in-place policy and deferred update policy, respectively. Commutativity relations are obviously not the only ones that fulfill these requirements.

Commutativity relations pose two requirements on a pair of operations. First, they require that the execution is legal in both orders and second, they demand that the states resulting from both execution orders are equivalent. A natural modification to reduce the number of conflicts is to drop the requirement for equivalent states.


Workspace A

I AI createNode(ln: Content, " ... ", Out: N1)

I A2 createNode(ln: Content, " ... ", Out: N2)

I A3 createNode(ln: Position, " ... ", Out: N3)

I A4 createLink(ln: RefersTo, N1, N2, Out: L1)

I AS addContent(ln: N1, " ... ")

I A6 deleteLink(ln: L 1, Out: RefersTo, N1, N2)

: AT deleteNode(ln: N2, Out: Content, " ... ") , ------ - - - - --- -- -- - - - - - - - - - - - - - - - - -- --:A7'--co~p(A7i---- ---- ----- -- ---- ------, -------------------------------------182 createNode(ln: Content, " ... ", Out: N4)

183 createLink(ln: RefersTo, N4, N2, Out: L2) I

Workspace B

AI createNode(ln: Content, " ... ", Out: N1)

A2 createNode(ln: Content, " ... ", Out: N2)

I A4 createLink(ln: RefersTo, N1, N2, Out: L1)

81 addContent(ln: N1, " ... ")

82 createNode(ln: Content, " ... ", Out: N4)

83 createLink(ln: RefersTo, N4, N2, Out: L2)

Figure 7.6 After import from workspace B into workspace A

In the following we therefore examine two other relations, namely recoverability (rev) [Badrinath and Ramamritham, 1992] and ignores (ign) [Herlihy, 1990]1, and discuss their applicability in the context of our model.

Definition 14 (recover ability relation)

Va, bE :E : (b, a) E rev:<=> V history hI, h2: hI. h2 is legal A

Definition 15 (ignores relation)

hI • [a] • h2 • [b] is legal ~

hI • h2 • [b] is legal

Va, bE :E: (b, a) E ign :<=> V histories hI, h2 : hI. [a]. h2 is legal A

hI • h2 • [b] is legal ~

hI • [a]. h2 • [b] is legal

These relations do not consider effects on subsequent operations. In case of reeoverability it is considered whether an operation is independent of a previous operation, i.e., the previous operation is not needed to guarantee a legal execution. In case of ignores an operation is not invalidated if another operation is executed previously, i.e., it remains legal.

Since rev considers the removement of operations from histories and ign their insertion, the rev relation may be used to compute closed subhistories (replace be) and the ign relation may be used to determine conflicts between different workspaces (replace Ie).

Note, that these relations are not weaker than backward and forward commutativity, respectively, i.e., be ~ rev and Ie ~ ign. This results from the fact


that commutativity relations, in contrast to rev and ign, examine only the execution of operations that follow directly one after the other. For an illustrative example ofthis difference, we refer to [Herlihy, 1990).

The lack of assertions about states has some interesting consequences. For instance, two operations, each consisting of a "blind write", are recoverable and ignore each other although they neither commute forward nor backward. This implies that, e.g., a single "blind write" corresponds to a consistent unit of work and can be subject of an information exchange. For the same reason, there are no conflicts if it is imported into the destination workspace.

We now examine the applicability of these relations and demonstrate that even for rather simple examples severe problems occur. Let us consider the case where both commutativity relations are replaced by the relations described above.

We augment the example introduced in Section 7.4 by adding an additional operation readContent{IN: Node, OUT: Content) which complements addContent by reading the content of a node. Table 7.3 and 7.4 show the conflicts between these two operations as induced by the relations recoverability and ignores, respectively. Note that these relations are in contrast to backward and forward commutativity not symmetric. The entry in the table indicates that the first operation is dependent on the second operation when the indicated condition holds.

Table 7.3 Conflicts between addContent and readContent using recoverability

addContent{IN: Nodel, Contentl) addContent{IN: Node2, Content2) addContent{IN: Nodel, Contentl) readContent{IN: Node2, OUT: Content2) readContent{IN: Nodel, OUT: Contentl) addContent{IN: Node2, Content2) readContent{IN: Nodel, OUT: Contentl) read Content {IN: Node2, OUT: Content2)

Operation pair Conflict predicate

False

False

Nodel = Node2 AND Content! = Content2

False

Let us assume that the user A has executed in this workspace a sequence of operations as depicted in Figure 7.7. In a previous merge user B had imported operation Al

Suppose, user B wants to import operation As. According to the definition of rev, two addContent operations do not depend on each other, i.e., operation As does not depend on operation A2 • As operation Al is already present in the workspace history of user B and as this is the only operation in the destination history, we do not encounter any conflicts. If user B next decides to import operation A2 , too, he or she is allowed to do so, and we get the situation shown in Figure 7.8.


Table 7.4 Conflicts between add Content and readContent using ignores

addContent(IN: Nodel, Contentl) addContent(IN: Node2, Content2) addContent(IN: Nodel, Contentl) readContent(IN: Node2, OUT: Content2) readContent(IN: Nodel, OUT: Contentl) addContent(IN: Node2, Content2) read Content (IN: Nodel, OUT: Contentl) read Content (IN: Node2, OUT: Content2)

Workspace A

I AI createNode(ln: Content, " ... ", Out: Nl)

I A2 addContent(ln: Nl, Textl)

I A3 addContent(ln: Nl, Text2)

I A4 readContent(ln: Nl, Out: Text2)

Operation pair

Workspace B

Conflict predicate

False

False

Node! = Node2 AND Content! -::j:. Content2

False

I AI createNode(ln: Content, " ... ", Out: Nl)

Figure 7.7 Workspace histories at the beginning of the example

Workspace A

I A I createNode(ln: Content, " ... ", Out: Nl)

1A2 addContent(ln: Nl, Textl)


I A4 readContent(ln: Nt, Out: Text2)

Workspace B

I A I createNode(ln: Content, " ... ", Out: Nl)


I A2 addContent(ln: Nl, Textl)

Figure 7.8 Situation after two further merges

If user B finally decides to import operation A4 , he or she would also be allowed to do so because the two conditions of our merge algorithm are satisfied:

(1) All other operations from the source history are present in HB. Hence, Condition 1 is trivially satisfied.

(2) All operations of HB are already contained in HA. Hence, Condition 2 is satisfied. Note, that we use here our notion of identical operations.

Nevertheless, the resulting history would not be legal. On the other hand, if we had used backward commutativity to determine closed subhistories, the first exchange would have resulted in the transfer of both instances of operation


type addContent from HA to HB, thereby ensuring that they occur in the appropriate order in HB.

One may argue that the reason for this anomaly is not the usage of relations that do not guarantee the equivalence of states but rather the policy of our exchange algorithm to check only for conflicts between operations that have not yet occurred in the source workspace (Condition 2). Our next example shows the virtue of this policy, and that its omission would introduce different anomalies.

Consider a slightly modified example where we make the additional restriction that there is an upper bound on the number of nodes of each type. In this case successive operations to create a node are no longer independent. If the upper bound has been reached the operation createNode returns an error code instead of a node identifier. The resulting semantic relations are depicted in Tables 7.5, 7.6 and 7.7.

Table 7.5 Conflicts for createNode using recoverability

Operation pair

createNode(IN: NTypel, Namel, OUT: Nodel f:. err) createNode(IN: NType2, Name2, OUT: Node2 f:. err) createNode(IN: N Type 1 , Namel, OUT: Nodel f:. err) createNode(IN: NType2, Name2, OUT: Node2 = err) createNQde(IN: NTypel, Namel, OUT: Nodel = err) createNode(IN: NType2, Name2, OUT: Node2 f:. err) createNode(IN: NTypel, Namel, OUT: Nodel = err) createNode(IN: NType2, Name2, OUT: Node2 = err)

Conflict predicate

False

False

NTypel = NType2

False

Table 7.6 Conflicts for createNode using ignores

Operation pair

createNode(IN: NTypel, Namel, OUT: Nodel f:. err) createNode(IN: NType2, Name2, OUT: Node2 f:. err) createNode(IN: NTypel, Namel, OUT: Nodel f:. err) createNode(IN: NType2, Name2, OUT: Node2 = err) createNode(IN: NTypel, Namel, OUT: Nodel = err) createNode(IN: NType2, Name2, OUT: Node2 f:. err) createNode(IN: NTypel, Namel, OUT: Nodel = err) createNode(IN: NType2, Name2, OUT: Node2 = err)

Conflict predicate

NTypel = NType2

False

False

False

Now, lets have a look at the history of user A shown in Figure 7.9. It consists of two successful createNode operations. Assume user B simply wants to import this history in two successive steps, i.e., first operation Ai and in a second import operation A2 •


Table 7.7 Conflicts for createNode using backward commutativity

Operation pair

createNode{IN: N'JIypel, Namel, OUT: Nodel -::j:; err) createNode{IN: N'JIype2, Name2, OUT: Node2 -::j:; err) createNode{IN: N'JIypel, Namel, OUT: Nodel -::j:; err) createNode{IN: N'JIype2, Name2, OUT: Node2 = err) createNode{IN: N'JIypel, Namel, OUT: Nodel = err) createNode{IN: N'JIype2, Name2, OUT: Node2 -::j:; err) createNode{IN: N'JIypel, Namel, OUT: Nodel = err) createNode{IN: N'JIype2, Name2, OUT: Node2 = err)


I AI craateNoda(ln: Contant, " ... ", Out: N1+ err) I I A2 creataNode(ln: Content, " ... ", Out: NU arr) I

Figure 7.9 User A has created two nodes

Conflict predicate

False

NTypel = NType2

NTypel = NType2

False

In case the merge algorithm checks conflicts between operations that have already been executed in the source workspace, this would not be permitted. After operation Al is imported, an attempt to import the second operation results in a conflict.

Even if we omit the conflict checks between operations that have already been executed in one workspace in the same order would be too strict. In this case we would not be able to import the second operation before the first one. This sequence would on the other hand be allowed if we ignore conflicts between operations that have already been executed in the source workspace regardless of the type of relations we use.

To summarize our comparison we state that the use of commutativity relations has the advantage that they (by nature of commutativity) exactly tell us when we are allowed to merge operations in a different order than originally executed (like in the second example) and when we are not allowed to do so, i.e., better import some previous operations, too (like in the first example).

Similar problems as described above occur if we replace only a single commutativity relation.

7.7 SUMMARY

In this Chapter, we have presented a formal description of the COACT model [Rusinkiewicz et al., 1995, Wasch and Klas, 1996, Klingemann et al., 1996). COACT provides a flexible framework to support cooperation in interactive, multi-user environments. After having given an overview of COACT we de-


scribed how we model a single user's work by means of workspace histories. We presented the merge mechanism that permits the semantically correct exchange of information among cooperating users and showed that correct merged histories remain legal. Furthermore, we discussed an algorithm which utilizes the idea of history merging to implement COACT'S exchange operations (import, delegate, and save).

To ensure the correctness of cooperation in COACT, we exploit the typespecific semantics of operations by means of both backward and forward commutativity relations. We use backward commutativity to identify dependencies between operations of the same workspace (history). We use forward commutativity to identify conflicts among operations executed in different workspaces.

In addition to commutativity relations, we discussed semantic relations that rely only on the values that are externalized to a user (and not on the workspace states). It turned out that these relations suffer from severe anomalies that may occur during merging histories (for further discussions see [Klingemann et aI., 1996]). For this reason, we think that the usage of backward and forward commutativity is the best choice for our model. These relations limit the number of conflicts (for example they introduce less conflicts than ordinary state-independent commutativity) while on the other hand preserving the correctness of the merge algorithm.

Regarding the units of exchangeable operations we follow a similar approach as in the operating system Gutenberg [Vinter et aI., 1986] where action dependencies (which result from interprocess communication between kernel objects and shared use of capability directories) are used to define recoverable computations. We use the dependencies between operations (induced by backward commutativity) to identify consistent units of work (closed subhistories) that can be subject to an exchange of operations among workspaces.

In COACT we guarantee that the view of each operation remains valid by exploiting its semantics. The system detects if the exchange of operations introduces inconsistencies and proposes alternative sets of operations that guarantee consistency of data.

We use the concept of identical operations to establish a closer cooperation among co-workers and their workspace (histories).

In COACT we achieve cooperation in terms of exchanging operations (and not data items) among workspaces. One may argue that the exchange of results in terms of data or documents, respectively is more natural from a user's viewpoint. We want to point out that the exchange of data items can be mapped to the exchange of a respective set of operations contained in a workspace history. Moreover, use of operations and exploiting their semantics enables a higher degree of cooperation than only exchanging data items (and, hence, going back to a read/write model).

Due to the fact that the COACT model allows to identify consistent units of work dynamically at run-time, it is well suited for cooperative environments in which the occurrence of conflicts cannot be determined at specification time, e.g., highly interactive and creative design processes like cooperative authoring.

8.1 INTRODUCTION

8 THE TRANSCOOP DEMONSTRATOR SYSTEM

Justus Klingemann

Susan Even

The demonstrator system is one of the main results of TRANSCOOP, realizing the most important concepts introduced in the project. Its purpose is to demonstrate the usefulness and applicability of the scientific results [TransCoop, 1994). For the implementation of the demonstrator system, we chose a subset of the concepts developed in the project, which was, on the one hand, powerful enough to demonstrate the TRANSCOOP approach to cooperation, and on the other hand, allowed a reliable implementation within the time frame of the project. The implemented parts include most of the tools of the specification environment, the COACT transaction model, as well as an enforcement mechanism for step constraints. The resulting demonstrator system allows us to show how cooperative scenarios are specified, validated, compiled for execution, and finally executed.

In Chapter 4, we investigated three application domains: Cooperative Document Authoring, Design for Manufacturing, and Workflow. The particular domain used for the demonstrator is Cooperative Hypermedia Document Authoring (CDA). This domain is easy to understand for a broad audience and it allows varied demonstrations due to its flexible working style. A lot of work has been done on hypermedia authoring at GMD-IPSI, including work on the SEPIA system. We therefore used the SEPIA hypermedia authoring system as the TRANSCOOP demonstrator application. This provides the possibility to en-

173




hance the authoring capabilities of SEPIA with the TRANSCOOP cooperation mechanism and allows to compare both approaches.

The chapter is organized as follows. Section 8.2 gives an overview of the TRANSCOOP demonstrator, describing its architecture and functionality. Section 8.3 describes the cooperative authoring application that is used in the demonstrator. Because this application is based on the SEPIA hypermedia authoring system, we include an overview of the authoring philosophy behind SEPIA and the functionality of this application. In the remainder of the chapter, the design of the TRANSCOOP demonstrator is presented. In Section 8.4, the design of the Demonstrator Specification Environment is described in detail. This description focuses on our tool set for supporting the specification and analysis of a scenario in CoCoA. The two compilers from CoCoA to the run-time environment are also discussed. In Section 8.5, the design of the Demonstrator Run-time Environment is described in detail. We first give an overview of the run-time architecture. After that, the main system components (the Cooperative Transaction Manager, the Cooperation Manager, and the Extended Graphical User Interface) are described. The chapter ends with conclusions.

8.2 OVERVIEW

Figure 8.1 shows the overall architecture of the TRANSCOOP Demonstrator System. The grey shaded components in the figure indicate the modules developed and implemented in the TRANSCOOP project; the unshaded components are pre-existing software modules.

The demonstrator system consists of two major components: the demonstrator specification environment (DSE) and the demonstrator run-time environment (DRE). The specification environment contains tools for editing cooperative scenarios, analyzing and simulating them, and compiling them into representations used by the run-time environment. The demonstrator run-time environment has a transaction management support system as its central component. Its cooperative transaction manager (CTM) and cooperation manager (CM) enable the execution of cooperative scenarios specified using the DSE.

The DSE provides all tools needed by a scenario designer to create new scenario specifications in CoCoA. The tools include a graphical specification editor, a parser/type-checker, tools for verifying user-specified correctness constraints within a scenario, two compilers, and a simulation tool. One compiler turns CoCoA specifications into cooperation manager control specifications; the other generates COACT transaction manager input specifications.

Recall from Chapter 6 that two different views of a scenario come together in CoCoA: an organizational view and a transactional view. We decided to reflect these two views in the demonstrator run-time structure. Thus, the DRE has separate modules to govern and coordinate the cooperation during a scenario execution (the CM), and to ensure the transactional correctness of a scenario execution (the CTM). The DRE also contains a Persistent Object Storage

THE TRANSCOOP DEMONSTRATOR SYSTEM 175

Actor Actor

TM Abstract Machine

Figure 8.1 The overall TRANSCOOP demonstrator architecture.

System, which is used to store compiled scenario specifications, run-time status information for the CM and CTM, VODAK-specific data, and applicationspecific data. The extended graphical user interface (EGUI) enables end-users to interact with the TRANsCoop demonstrator system.

The demonstrator is partially based on existing technology. The demonstrator specification environment builds on the existing TM Abstract Machine [Flokstra and Boon, 1996], which has been developed at UT. The demonstrator run-time environment is based on the VODAK object-oriented database management system [GMD-IPSI, 1995]. The cooperative hypermedia document authoring application of the demonstrator and its specialized graphical user interfaces is based on the SEPIA hypermedia authoring environment [Streitz et al., 1989]. For the TRANSCOOP demonstrator, we used the VODAK-based implementation of the SEPIA system [Wasch and Aberer, 1995, Bapat et al., 1996b].

In the following paragraphs, we describe the overall functionality of the TRANSCOOP demonstrator system by "walking through" its components to highlight their use and dependencies. The components are explained in detail in later sections.

1. Specification Environment.


(a) Graphical Scenario Editor. A scenario designer uses the graphical editor to build and structure a CoCoA specification. A back-end to the graphical editor generates a textual representation of the specification, which is stored in the file system where it can be accessed in later stages of development.

(b) Static A nalysis Tool. This tool performs static analysis checks on the new specification. At its core lies a parser/type-checker. The tool checks a number of context-sensitive requirements related to the definition and use of operations and communications.

(c) Dynamic Analysis Tool. This tool is used to simulate the organizational behavior of a CoCoA specification using the TM Abstract Machine. To do this, the specification is mapped to a TM schema that defines data structures and operations for storing and manipulating meta-information about the dynamic state of the scenario. During simulation, the scenario states are displayed using the da Vinci Graph Visualization Tool.

(d) CoCoA to CM Compiler. This compiler maps the organizational aspects of a CoCoA specification to control definitions that are needed by the Cooperation Manager of the run-time environment. The compiler retrieves the CoCoA sources from the file system and stores the compilation results in the Specification Database of the run-time environment.

(e) CoCoA to CoAct Compiler. This compiler maps those parts ofa CoCoA specification that are needed by the COACT transaction model to input specifications for the Cooperative Transaction Manager. The compiler retrieves the CoCoA sources from the file system and stores the compilation results in the Extended VODAK Data Dictionary of the run-time environment.

2. Run-time Environment.

(a) Extended Graphical User Interface. To support user interaction in the exchange of results, the TRANSCOOP interface to the SEPIA system extends it with facilities for manipulating workspace histories, such as selecting operations for exchange and resolving merge conflicts.

(b) Status Database. This database stores administrative information to support a scenario's execution, such as the workspace histories of the users participating in the scenario, and the run-time structure of the step specification.

(c) Cooperation Manager. The Cooperation Manager monitors the organizational aspects of a scenario. It verifies that each requested data, exchange, or communication operation is in fact permitted by


the CoCoA scenario specification at the particular time when it is requested.

(d) Cooperative Transaction Manager. The Cooperative Transaction Manager implements the basic functionality of the COACT transaction model. It maintains workspace histories, computes dependencies and conflicts between operations, and implements the history merging algorithm.

8.3 THE DEMONSTRATOR APPLICATION

In this section, we describe the hypermedia authoring system SEPIA [Streitz et al., 1989]. In the TRANSCOOP demonstrator, this application has been enhanced with the cooperation facilities developed within TRANSCOOP to allow cooperative hypermedia authoring according to the TRANSCOOP paradigm.

In our overview of the SEPIA system we focus on the implementation variant that is based on VODAK. This means that the SEPIA system is modeled as a database schema. We abstract away from the detailed operations and limit ourselves to a general description of the system functionality.

8.3.1 Cooperative Hypermedia Document Authoring

Cooperative Hypermedia Document Authoring is characterized by multiple authors working on (one or more) common hypermedia documents. In contrast to traditional, linearly structured documents, the concept of hyperdocument allows to have networked structures. A hyperdocument consists of nodes and connecting links, which enable authors to create and present associative reference structures within and between documents. The nodes contain multimedia information, such as text, pictures, and audio. The general objective of a hypermedia authoring process is the creation of a "hyperdocument" artifact.

8.3.2 Overview of the SEPIA Hypermedia Authoring System

The development of SEPIA (Structured Elicitation and Presentation of Ideas for Authoring) was based on a cognitive model of the hypermedia authoring process. The basic functionality of SEPIA is provided via the concept of activity spaces to support the different activities of the authoring process (i.e., planning, content acquisition, development of an argumentation structure, and preparation of the final document). The SEPIA system supports plain text, graphics, pictures, and audio as contents of nodes. Its functionality is provided to the user via a graphical user interface.

Because the TRANSCOOP demonstrator implementation is based on the OODBMS VODAK [GMD-IPSI, 1995, Klas et al., 1994a], we have used the VODAK-based implementation of the SEPIA system in the TRANSCOOP project. The particular version of the SEPIA system uses Java for its graphical user interface. For details on the design of the SEPIA system implementation


based on VODAK, we refer the reader to [Wasch and Aberer, 1995, Bapat et al., 1996b, Bapat et al., 1996a].

8.3.3 Graphical User Interface to the SEPIA Hypermedia System

To provide the end-user authors with access to the hypermedia data, a graphical user interface (GUI) to the SEPIA database schema has been implemented. This GUI visualizes the hypermedia data as stored in the database and allows the user to access and manipulate it (Le., navigation through and modification of the hypermedia structures). To give the reader an impression of the functionality of the SEPIA system available to authors, we describe in the following the graphical user interface of the conventional (Le., non-TRANSCOOP) SEPIA system.

tl~T)'t:u

IJ*Mr,," ~.fw;fo.eor.-, "tftTc; J.ni"'tN i_Ii

Figure 8.2 The graphical user interface of the SEPIA system

Figure 8.2 shows the graphical user interface of SEPIA (implemented in Java). SEPIA supports the hierarchical structuring of documents. The top level consists of (logical) databases. Each database is divided into SEPIA authoring projects. SEPIA provides the notion of activity spaces, which are represented by separate windows for different tasks within each authoring project (e.g., planning the document structure, content acquisition, or the development of argumentation structures). Task-specific node types, link types, and content types are available within these activity spaces. These types are implemented in the SEPIA database schema as different application classes. The available


node and link types in a specific activity space are displayed in a palette on the left-hand side of the browser. The palette is also used to create new nodes and links. Depending on their type, nodes have different menus to create and access their contents. Nodes in SEPIA can be either composite or atomic. Composite nodes of the hypermedia data model represent subspaces similar to the activity spaces mentioned above. These are visualized as a separate space browser in the GUI. For atomic nodes, different content types (text, audio, etc.) can be created, depending on the content types defined for the respective node type, as specified in the database schema.

The operations offered by the SEPIA database schema are invoked by the GUI using VODAK's method call interface. For example, if a user requests to open a composite node (by selecting an 'open' command from the node's pop-up menu) a corresponding method call is sent to the SEPIA system. The SEPIA database then returns information about the contents of the composite node. Using the information returned, the graphical user interface can present the contents of the opened composite node in a browser to enable the user to access and manipulate the data.

8.3.4 Cooperation in SEPIA Compared to TransCoop

In the following, we describe how the interaction of multiple users is handled in the original SEPIA system and relate this to the concepts available in the TRANSCOOP paradigm.

The main difference between the two approaches is that SEPIA does not have the concept of different workspaces but has only a single global state. Hence, in SEPIA each operation is immediately broadcast to all other co-workers. A central component serializes all operations. In COACT, this corresponds to a behavior where each operation is delegated immediately to all other coworkers. Therefore, the histories in all workspaces would be similar. However, in contrast to COACT, the SEPIA users do not have the possibility to perform individual work and develop individual ideas without co-worker interference. All modifications by other users working in the same activity space are visible immediately, not on demand as in COACT.

In addition to this so-called loosely coupled mode, where only the content of the space is updated according to the actions of other users, the co-workers can also decide to switch to the tightly coupled mode, during which scrolling and resizing events of the display are immediately broadcast.

Another issue is the treatment of dependencies operation dependencies and conflicts operation conflicts between operations. If, for example, a user reads the text in an atomic node and later writes back the modified text, it has to be ensured that in between these events, the text has not been changed by another user. SEPIA handles this by implicitly grouping read and write operations on the same object. In case of a conflict only one of the users is able to execute the write operation. The other user is informed that he or she is too late and the work is inevitably lost. In the COACT model, dependencies are recognized


by commutativity relations. This allows a more precise detection of dependencies. The same holds true for conflicts between operations of different users. They can be reduced as the use of commutativity results in fewer conflicting operations. In addition to this, the conflicts need not be resolved immediately because each user works in his or her private workspace. The users can decide on demand (Le., when they see the work in a broader context), which result should be in their workspace.

8.4 THE SPECIFICATION ENVIRONMENT

In this section, we describe the components of the specification environment that were implemented as part of the TRANSCOOP demonstrator system. A more substantial tool set architecture is described in [Even et al., 1996c].

8.4.1 Graphical Scenario Editor

The GRACOOP Scenario Editor is a graphical front-end tool to assist the specification designer in creating a CoCoA scenario [Faase et al., 1996]. It is based on a graphical modeling method called GRACOOP (Graphical Language for Cooperative Processes), which is described in [Even et al., 1996c]. The graphical editor's functionality builds on a step diagraming technique that allows the specifier to model the organizational structure of a cooperative scenario as a graph. Step diagraming copes with the complexity and hierarchical nature of a scenario by decomposing the structured parts of the scenario into subgraphs. Additional, non-graphical information is specified using dialog boxes and editing windows; this information annotates the graphical elements of the step diagram. There is also a matrix tool for entering commutativity specifications.

Once a scenario is specified, a back-end to the graphical editor generates a textual CoCoA specification, which can be input to the static analysis tool, and the compilers to the run-time environment. The graphical editor has been implemented using the MetaEdit+ Method Workbench, which supports the development of graphical modeling methods and tools [MetaCase, 1996]. A graphical representation of the step structure of a scenario to write a technical report using the TRANSCOOP demonstrator is shown in Figure 8.3. (For a detailed description of this scenario, see [Even et al., 1996a].)

8.4.2 Static Analysis Tool

At the core of the static analysis tool lies a parser/type-checker for CoCoA. The parser/type-checker checks the correctness of a specification according to the CoCoA grammar that was given in the appendix to Chapter 6. The static analysis tool performs a number of additional well-formedness checks, which are summarized below:

• it type-checks all embedded TM expressions,


Figure 8.3 Graphical representation of nested, multiple activation steps.

• it checks on the correct use of steps, points, data operations, data exchange operations, and communications in all parts of the input CoCoA specification,

• it checks the correctness of transitions (e.g., whether each interaction point is connected to some transition),

• it checks whether all defined communications are used, and whether they result in consistent step (de ) activations with respect to the defined transitions,

• it checks reach ability of the organizational parts of the scenario, and

• it checks whether the execution order rules are deterministic.

Appropriate warning messages are generated when a specification does not pass the above tests. In our experimentation with the static analysis tool, we have found that many specification errors can be detected by the tool.

The CoCoA static analysis tool is implemented in C++; the software extends an already existing parser/type-checker for TM [Bal et al., 1996]. The static analysis tool implements several back-end output generators, which are activated via a command-line switch. The back-ends consist of two compilers to the run-time environment, and a mapping to a TM schema suitable for simulation using the dynamic analysis tool.

8.4.3 Dynamic Analysis Tool

The dynamic analysis tool offers facilities for the study of the execution properties of a scenario specification. An objective in the design of this tool was to


build on existing technology. To this end, we utilized the TM Abstract Machine [Flokstra and Boon, 1996], and the da Vinci Graph Visualization Tool [Frohlich and Werner, 1994].

The dynamic analysis tool simulates the organizational behavior of a CoCoA specification, using the TM Abstract Machine. To do this, the specification is first mapped to a TM schema that defines data structures and operations for storing and manipulating meta-information about the dynamic state of the scenario. (This meta schema is generated by the static analysis tool.) During simulation, the scenario states are displayed using the da Vinci Graph Visualization Tool. Using simulation, the scenario specifier can check whether the scenario behaves as expected. By issuing queries over the scenario state graph (represented as a TM database), the specifier can investigate properties that the scenario is required to have.

Although the simulation environment is restricted to the organizational aspect, it allows to study many possible execution paths in parallel, instead of a single execution of a scenario instance as in the run-time environment. This is achieved by keeping track of all possible states of the scenario, and allowing the specifier to investigate alternative choices. A transition graph is built from the states and the transitions between the states; transitions are the result of executing communication operations.

A Java program implements a user interface to the dynamic analysis tool, which directs the simulation. This program executes TM queries on the scenario state graph stored in the TM Abstract Machine, and it issues TM update methods to modify the scenario state graph. The program interacts with the da Vinci tool to display the transitions between scenario states and to process commands given through the da Vinci interface. Via the user interface to the dynamic analysis tool, the specifier can observe which operations (data, data exchange, and communications) are enabled at each visited state of the scenario. (See Figure 8.4.) Communications can be invoked at a particular state to arrive at another state. With the analysis tool, it is possible to automatically expand the scenario graph, based on a given set of communications for which parameter values are known. The closure of the graph is computed with respect to these communications. A scenario graph that has been generated can then be queried, using TM's powerful query expressions. This technique offers a means to investigate the dynamic properties of the scenario under investigation.

8.4.4 Compilers

There are two compilers from CoCoA to the run-time environment: the first compiles the transactional aspects of a CoCoA scenario into input files that are used by the Cooperative Transaction Manager; the second compiles the organization aspects of a scenario into a data structure that is used by the Cooperation Manager to manage the organizational constraints of the cooperative activity. Both compilers are described in detail in [Even et al., 1996a].


Figure 8.4 Nested Java menus showing the 'createNode' data operations that are enabled for user 'Thomas' during the 'make_planning' step of simulation.

CoCoA to CoAct Compiler. The CoCoA to COACT Compiler generates two output files for a given specification: one contains the commutativity conflict definitions, and one contains the compensation rules. These files are directly used by the Cooperative Transaction Manager of the run-time environment.

CoCoA to CM Compiler. The CoCoA to CM Compiler generates the data structures that are used by the Cooperation Manager during the execution of the scenario. These data structures take the form of an object network, which captures the organizational structure of the scenario. The compiler stores the object network in the Specification Database for later interpretation by the Cooperation Manager as it controls the execution of the compiled scenario.


8.5 THE RUNTIME ENVIRONMENT

This section describes the demonstrator run-time environment and in particular the cooperative transaction manager (CTM), the cooperation manager (CM), and the extended graphical user interface (EGUI).

d:§ .. ~ ~c~~,

Data DIctlOn81Y .

Figure 8.5 The run-time architecture of the TRANSCOOP demonstrator system.

Before the different modules are described we give a brief overview of the overall architecture.

8.5.1 Run-time Architecture

The demonstrator run-time architecture presented in Figure 8.5 is an implementation of the run-time part of the TRANSCOOP reference architecture defined in Chapter 5.

Each workspace is realized within TRANS COOP by means of a separate application database as well as a separate process consisting of a modified VODAK system, the cooperative transaction manager containing the merge functionality, and the cooperation manager governing the execution of steps. On top of these components the SEPIA graphical user interface is located.

Most of the TRANSCOOP specific functionality of the run-time system is realized on top of VODAK, e.g., within the CTM or CM. This makes the

THE TRANS COOP DEMONSTRATOR SYSTEM 185

implementation less dependent on the VODAK system. In addition to this, it reduces the complexity of the system as the interface to existing components can be small. On the other hand, functionality that is closely related to the existing components of VODAK is realized as an extension or replacement of existing VODAK modules. This is the case for the management of the different workspaces and their object versions. In the normal VODAK system all users working on the same machine share the same object buffer. In the TRANSCOOP system we assign to each workspace a separate object buffer containing the private object versions of the respective user.

VODAK is an object-oriented DBMS developed at GMD-IPSI. VODAK provides a database management system kernel including message handling, object management and object buffering. However, the physical management of the VODAK objects on disk is performed by a storage manager. This task is currently performed by the C++ based database system ObjectStore. In the TRANSCOOP run-time system we enhance the usage of ObjectStore by storing additional data in ObjectStore databases.

The replication of the VODAK system (including its object buffer) as well as the application database makes sure that the data elements of different workspaces are isolated. The application database is replicated at the start of a cooperative activity and an additional copy is generated when a new user joins the scenario. When a user wants to access an object it is loaded from the private application database to the private object buffer which belongs to this workspace. Modifications are written back only to the private application database. The different workspaces can be located on the same machine or be distributed among different machines.

An important part of the run-time system design is the Status-DB. It maintains the workspace histories of the participating users and the run-time structure of the step specification. It also provides general administrative information among different workspaces, e.g., the current participants of the scenario or the operations enabled by the current step. The status database resides within ObjectStore. Therefore, we can make use of the ObjectStore transaction management like concurrency control and the recovery of run-time data structures. However, for different application domains like mobile environments which are outside the scope of this demonstrator implementation other realizations are more appropriate [Klingemann et al., 1997].

The cooperative transaction manager offers functions to preview the progress of co-workers by means of querying their histories in the Status-DB, and provides operations for both the calculation of possible merge alternatives and the enforcement of a particular exchange by merging workspace histories according to the users selection.

Users can join an ongoing scenario execution as well as leave the scenario before it is finished as specified in CoCoA. The termination of the scenario is possible if the scenario is in a termination state which is evaluated within the step mechanism. On termination, all private application databases are


removed and the application database of the common workspace represents the final result.

The SEPIA GUI module contains the user interface functionality of the SEPIA application. It visualizes the hyperdocument structure and provides means for their graphical manipulation. All modifications of the hyperdocument structure are propagated as method invocations to the VODAK DBMS, i.e., the private workspace of the respective user. The VODAK client/serverAPI allows to propagate the invocation information over the network, coded in an internal message format. Note that the client software can be implemented in any language (in our case Java) as long as there is a VODAK client API available.

Besides the simple execution of method calls, the extended SEPIA GUI provides TRANSCOOP specific interfaces giving the user access to the cooperation facilities of the system. These functions comprise the merge functionality covered by the cooperative transaction manager as well as the management of steps provided by the cooperation manager. A TRANSCOOP service request is directed to the corresponding system module (CM, CTM). Ordinaryapplication method invocations are executed under the control of the modified VODAK system residing in the respective workspace. Invocations are recorded in the Status-DB together with other relevant information. The Application-DB and the data dictionary serve similar purposes as in the traditional VODAK system.

8.5.2 Cooperative Transaction Manager

The cooperative transaction manager is a run-time module that implements the basic functionality of the TRANSCOOP cooperative transaction model COACT. Besides the cooperation manager (CM), the cooperative transaction manager (CTM) is the core component of the TRANS Coop demonstrator run-time environment (DRE).

A major task of the CTM is to generate and maintain the workspace histories. The workspace histories are realized as double-linked lists which are stored in the status database. To make sure that each data operation to be executed in a workspace is recorded in the workspace history all requests to execute an operation that are send to the VODAK message handler are caught by the CTM. The CTM uses the information in the message call to generate an entry in the workspace history. Once a history entry is generated it will never be removed from the history. We made this implementation decision to allow for further extensions to analyze the working process after the end of a cooperative activity. If a history entry has to be logically removed from the history, i.e., it is compensated, the compensated history entry as well as its compensating operation are marked as invalid in the history. This implies that they are ignored for future checks for dependencies or conflicts.

To initiate an exchange operation the CTM provides the possibility to query the workspace histories of all participants, e.g., the own workspace history in


case of a delegate operation or the workspace history of a co-worker in case of an import operation. A user can request the whole workspace history or restrict the search to operations of certain types or specific receiver objects. The CTM offers the function request_work for this purpose.

To perform a merge, the CTM offers two functions. The first function check...merge allows the user to check for possible merge conflicts. The user provides by means of the G UI a selected set of operations to merge from a source history into a destination history. The function then returns those operations of the destination history which need to be compensated to integrate the selected operations. The operations to be compensated are grouped by the operations selected by the user. Hence, the user can see what implications the merge of each operation has. (For details on the visualization of the merge see Section 8.5.4.) The function check...merge detects not only direct conflicts, i.e., operations in the destination history which do not commute forward with one of the selected operations, but also indirect conflicts. For example for each selected operation the minimal closed subhistory is calculated and all operations in the destination history conflicting with one of these operations are detected. To perform the actual integration task the CTM provides the function force...merge. This function has similar input as check...merge. It compensates and re-executes operations in the destination workspace as necessary. Merge conflicts are resolved by compensating all conflicting operations in the destination history.

To illustrate the purpose of these operations let us look at the typical sequence of function calls to the CTM to perform an import. The user first browses the workspace histories of other users (or the common workspace) by means of calls to the CTM function request_work. After choosing certain operations of a co-worker (or the common workspace), the user calls check...merge to get informations about work which might possibly get lost in his own workspace due to this merge. The information obtained this way might lead to the decision not to import certain operations. If the user has finally decided to import a certain set of operations which either have no merge conflicts or only those which the user is willing to tolerate, the user calls force...merge to complete the merge.

In contrast to import and save in the case of delegate the user who initiates the exchange operation is different from the user who integrates the delegated data operations into the destination workspace. Therefore, the delegation operation is executed in two steps. In the first step the delegator selects the operations to be exchanged in the history of his own workspace. This exchange history is then stored in a dedicated location of the status database. From there the delegatee can retrieve on demand the history and integrate it into his own workspace similar to the case of import.

Special care has to be taken for the re-execution of operations who generate new objects. Remind that in the COACT model exchange of information is performed by exchanging operations and not data. Therefore, newly created objects are made available to co-workers by exchanging the operation that cre-


ates the objects. When an object is created in VODAK, it is assigned a unique object identifier (OID). This OID can by viewed as a system generated input parameter to the operation. To make sure that the re-execution of the creating operation behaves analogously to the original method execution and all subsequent operations refer to the same object, we have to assign the same OlD during re-execution. In VODAK there is a counter which denotes the next OlD that will be generated. To enable the correct OlD generation for the reexecution, we store the value this counter has prior to the initial execution in the corresponding history entry. For the re-execution we set the counter used for OlD generation temporary to the stored value. Since the merge algorithm guarantees that the re-execution behaves like the original execution, we know that the same objects will be generated in the same order. Hence, the counter has at the time of each OlD generation the same value as for the initial execution. This ensures that the generated OIDs are the same as for the initial execution.

8.5.3 Cooperation Manager

The cooperation manager (CM) is a module of the run-time system which makes sure that the work proceeds in line with the organizational constraints of the scenario. This means that the CM has to maintain the step structure as specified in the scenario and check whether the requested operations are allowed by the currently active steps. To perform this task, the CM is located in the architecture of the TRANSCOOP run-time system between the graphical user interface and the CTM. All user requests go through the CM before they can be executed.

Possible operations that have to be checked by the CM include the ordinary data operations and meta operations like data exchange operations and communications. Every time one of these operations is requested, the CM checks whether the requested operation is enabled. This check depends on the parameters of the operation as well as the role of the user who wants to execute it.

Data operations and data exchange operations are passed to the CTM if they are enabled. On the other hand, communications are processed within the CM itself. Communications change the internal state of they CM as they trigger a step transition. Operations which are not enabled by one of the active steps are rejected by the CM.

In addition to checking operations when they are requested by the user the CM also provides facilities to inform the user about the currently active steps and the enabled operations. This gives the user the possibility to preplan his future activities.

The CM makes use of the specification database as well as the status database. The specification database is used to store the organizational part of a scenario specification in an internal format. The transformation of the CoCoA specification into this internal format is performed by the CoCoA to CM com-


piler (see Section 8.4). The status database holds the dynamic run-time data structures needed to execute scenario instances.

8.5.4 Extended Graphical User Interface

The design and outlook of the extended graphical user interface (EGUI) for the run-time demonstrator is based on the existing graphical user interface to the SEPIA system. To make the functions provided by the cooperation manager and the Cooperative Transaction Manager available to authors using our cooperative SEPIA system, the graphical user interface has been extended in the TRANSCOOP project.

Because user interface design is beyond the scope of the TRANSCOOP project, work on the graphical user interface has been minimal. We have only implemented the functionality that is necessary to demonstrate the applicability and usability of the TRANSCOOP concepts.

Figure 8.6 Selecting operations to be imported .

The functionality of the TRANSCOOP extensions can be accessed by different pull-down menus which have been added to the SEPIA user interface.

One menu allows to execute data exchange operations. It has menu entries to initiate an import, delegate, or save operation as well as to receive a delegation. In the following we will explain the case of import in more detail. When initiating an import, the user can first decide by means of a submenu whether to import from the workspace of a co-worker or from the common workspace. After selecting one option the user will be presented a window with three


Figure 8.7 Analyzing merge conflicts.

columns (see Figure 8.6). If the workspace of a co-worker has been selected as the source of the merge, in the upper part of the left column all co-workers are listed. The user can select a workspace by clicking on the entry for a co-worker. In case of a merge from the common workspace this choice is not necessary, as there is only one unique common workspace. In the lower part of the left column all operation types are listed. By selecting only some of these types the user can constrain the subhistory to inspect. The button Select All Methods selects the whole history. By pressing the button Request Work the selected subhistory of the source workspace is visualized in the column in the middle. Clicking on an operation gives more details on this operation in the right column. Using the mouse the user can now select the operations to be imported. Pressing the button Select All selects the whole subhistory. If the user has made a choice, he or she can press the button Continue. This activates the function check...lllerge of the CTM and opens another window (see Figure 8.7). The upper left part shows the selected history to be imported. Operations which have conflicting operations in the destination history are marked with the tag (Conflict) . Clicking on an operation shows the conflicting operations


in the upper right part of the window. The lower part of the window is used to provide details of selected operations. Having the additional information about merge conflicts the user can now make the final decision which operations to import. The merge is completed when the user clicks on the button Force Merge that invokes the CTM function force..merge.

Besides the exchange operations itself the EGUI provides additional functionality related to the CTM. On the one hand the user can access functions of the CTM which perform certain subtasks of the merge process like showing the list of co-workers, browsing workspace histories, calculating consistent units of work, or checking for merge conflicts. This can be used for debugging purposes and to experiment with the system. On the other hand the user has access to additional functionality. The most important one is to retract decisions by undoing parts of his own work. When the user selects operations to be compensated, he or she is informed about those operations that depend on the operations to be compensated. If the user confirms the undo, the dependent operations will be undone, too.

A separate pull-down menu is used to interact with the CM. The menu entries allow the user to get informations about the currently active steps, the enabled operations, i.e., data operations, exchange operations and communications, and to initiate a communication. In the visualization of the data operations the user is informed about all enabled operation types and for each type about possible restrictions on parameters. For the exchange operations all workspaces which can be used for exchange are listed together with the enabled types of operations on each workspace, i.e., import, delegate and save. The enabled communications are visualized in the context of the steps to which they belong.

8.6 SUMMARY

This chapter described the design of the TRANSCOOP demonstrator system. The demonstrator system is used to show how cooperative scenarios are specified, validated, compiled for execution, and finally executed. The particular domain of demonstration is Cooperative Hypermedia Document Authoring. The demonstrator scenarios are based on the SEPIA hypermedia authoring system of GMD-IPSI. Section 8.3 gave an overview of the VODAK-based implementation of the SEPIA system.

Section 8.4 gave an overview of the demonstrator specification environment. The specification environment contains the tools needed by a scenario designer to create and analyze cooperative scenario specifications written in CoCoA. The tools include a graphical scenario editor, a parser/type-checker, tools for verifying user-specified correctness constraints within a scenario, two compilers, and a simulation tool. One compiler turns CoCoA specifications into cooperation manager control specifications; the other compiler produces COACT transaction model specifications.


In Section 8.5, we described the design of the demonstrator run-time environment in detail. The run-time environment is based on the VODAK objectoriented database management system. The two scenario views manifest in CoCoA, namely the organizational view and the transactional view, are reHected in the demonstrator run-time structure. The run-time environment has separate modules for ensuring organizational correctness during a scenario execution (i.e., the cooperation manager), and for ensuring the transactional correctness of a scenario execution (i.e., the cooperative transaction manager). Both the cooperation manager and the cooperative transaction manager are integrated within VODAK. The run-time environment also contains several databases, which are used for storing compiled scenario specifications, runtime status information for the CM as well as of the CTM, VODAK-specific data, and application-specific data. The extended graphical user interface is based on the GUI of the pre-existing SEPIA system and enables end-users to interact with the TRANSCOOP demonstrator system.

9 CONCLUSIONS Susan Even

Thomas Tesch

Jari Veijalainen

In this chapter, we reflect on the goals of the TRANSCOOP project, on the methods applied to reach the goals, on the final results of the project, and on open issues and directions for future research.

The TRANSCOOP project had rather ambitious goals considering its size of less than 300 person months. The overall objective of the TRANSCOOP project was to develop appropriate concepts and techniques to provide transaction management support for cooperative applications. This included (i) the development of an appropriate specification language that allows to model cooperations between collaborating partners (e.g., application programs, users), and (ii) the development of an advanced cooperative transaction model that provides for the appropriate execution of the cooperation according to the specifications given in the specification language. These were also to be implemented in order to show the feasibility of the concepts developed.

The project thus combined aspects of four different disciplines, namely, transaction management, computer-supported cooperative work (CSCW), formal specification, and software development. As far as we know, the combination was unique at the time the project was planned.

The level of ambition was raised by the approach, by choosing to bring the four disciplines together. Instead of only looking at the literature (which we also extensively did to grasp the state of the art), we followed 'the long path' in TRANSCOOP. That is, it was decided to first investigate real cooperative application areas and deduce from them requirements for the transaction model, for

193




a suitable architecture, as well as for a suitable specification language. Based on the requirements deduced from three application areas (Cooperative Document Authoring, Design for Manufacturing, and Workflow Systems) (see Chapter 4 for details), a generic architecture of the cooperative transactional framework was first developed. It was called the TRANSCOOP Reference Architecture. The first versions of the transaction model and the specification language were developed in parallel with the architecture work during the first year. These were both then refined during the second year. Finally, the architecture was instantiated as the TRANS Coop demonstrator, which is a prototypical transactional framework consisting of the specification language, certain verification tools, and compilers to map the specifications to a form executable within the TRANSCOOP run-time system. The run-time support for the TRANSCOOP cooperative transaction model is provided by the run-time system that was implemented.

One important and unique goal of the TRANSCOOP approach was the development of concepts and software tools to verify certain transactional properties at specification time. This was based on the pre-understanding that to correctly specify such complicated computations as cooperative transactions would not be an easy task for a user. Being able to see how to verify these properties would also help in correctly implementing the run-time system.

Initially, the TRANSCOOP consortium also aimed at a unified formal model of the concepts developed for the specification language and the transaction model, because it was not evident how to relate the two levels. But due to time limitations in achieving the (rather ambitious) project goals, the development of the theoretical framework to unify the specification language and transaction model was left to future research. In the following sections, we reflect on the project accomplishments and remaining goals. Finally, we offer some guidelines for further research concerning the development of transactional frameworks.

9.1 REFLECTIONS ON THE COOPERATIVE TRANSACTION MODEL

The development of the cooperative transaction model focused on two main issues: the development of a merge mechanism to establish cooperation between users, and the development of execution rules to cover the execution structure of a cooperative application. Both tasks were of high complexity and many revisions of ongoing work were necessary during the project. The merge mechanism was discussed at length in Chapter 7.

During execution rule development, we first followed the approach of Klein [Klein, 1991], as reflected in the papers [Rusinkiewicz et al., 1995, Tang and Veijalainen, 1995a, Tang and Veijalainen, 1995c]. Later, it turned out that a completely new mechanism was needed, more powerful than the approaches presented in the literature. However, due to time limitations and the complexity of the task, a mechanism to enforce execution rules was omitted from the TRANSCOOP demonstrator.

CONCLUSIONS 195

Our work on the theoretical framework to link the specification language and the transaction model investigated the expressive power of the execution rules needed, especially in workflow environments. In [Tang and Veijalainen, 1995b], the transactional requirements deduced in [Tesch and Verkoulen, 1995] are related to the modeling means adopted by the project (as outlined in [Rusinkiewicz et al., 1995]). It turns out that the so-called Klein rules (existence and ordering dependency), on which the work in [Attie et al., 1993] is largely based, do not suffice in cases where operations of the same type must be repeated. A generalization of the existence and ordering dependencies to cope with multiple instances was investigated. However, work linking the execution rules of the CoCoA language to the Klein-rules extension was not completed within the time frame of the TRANS Coop project.

In general, the approach of the TRANSCOOP cooperative transaction model is a continuation of the work on semantics-based transaction models. To ensure the correctness of cooperation in the COACT model, we exploit the type-specific semantics of activity instances by means of both backward and forward commutativity relations. Backward commutativity is used to identify dependencies between activity instances of the same workspace (history). Forward commutativity is used to identify conflicts among activity instances executed in different workspaces.

The approach to utilize operation semantics in order to support cooperation is beyond the current state of the art of commercially available cooperation and transaction models and it is new in the research community. At the time of writing, COACT is the only transaction model we are aware of that takes operation semantics at run-time into account to allow end-user cooperation. From a scientific viewpoint, the results delivered by the TRANSCOOP ESPRIT Basic Research Project are significant. Further work is needed to transfer these results into practical applications.

The developed mechanism of exchanging histories is applicable to other problems in data management, such as version merging, replication control, and disconnected operations in mobile systems, as illustrated in [Klingemann et al., 1997].

9.2 IMPLEMENTATION OF CONCEPTS

The key software components designed and implemented as part of the TRANSCOOP demonstrator included:

• design and implementation of compilers from the TRANSCOOP specification language CoCoA (Coordinated Cooperation Agendas) to the VODAK run-time system (which includes a cooperative transaction manager and a cooperation manager),

• design and implementation of the TRANSCOOP specification environment to help a specifier of a cooperative scenario work with CoCoA by support-


ing the early conceptual design phases as well as the late testing phases of cooperative application development,

• design and implementation of the TRANSCOOP cooperative transaction model COACT (the Cooperative Activity Model), including the cooperation mechanism based on merging the work of cooperating users, and its integration in the VODAK DBMS,

• design and implementation of a run-time module (the cooperation manager) that realizes the step mechanism of CoCoA, and its integration in the run-time environment.

The TRANSCOOP demonstrator system shows the applicability of our approach in present-day information systems.

9.3 CRITICAL ASSESSMENT

Early in the TRANSCOOP project, it was determined through analysis of the application areas that there is a significant semantic gap between the LOTOSjTM specification language defined in the project [Even et al., 1996b), and the application scenarios to be defined in this language. It is not the case that LOTOSjTM is inappropriate for cooperative scenario definition, but rather, it is more the case that too many details must be specified when LOTOSjTM is used. This causes the specifications of even simple workflow scenarios to quickly become unmanageable in size. For this reason, the consortium decided to define the more user-friendly, more declarative specification language CoCoA on top of LOTOSjTM. Our original intention was that the semantics of CoCoA would be defined in terms of LOTOSjTM.

CoCoA includes some features for the declaration of data-model dependent information about the data operations, which is needed by the TRANSCOOP cooperative transaction model, such as commutativity relations [Faase et al., 1997). These features provide what we refer to as the transactional aspects of a scenario. CoCoA includes other features to support actor roles, communications, and operation enabling according to the organizational requirements of a scenario. These features provide what we refer to as the organizational aspects of a scenario. Some aspects of the semantics of CoCoA are highly dependent on the transaction model, the workspace histories that it maintains, and the merge algorithm used to exchange data (operations). For this reason, it is not possible to provide a complete semantics for CoCoA without appealing to the semantics of the transaction model underneath. In some respects, this seems a natural consequence of defining a language geared towards the specification of multiple-user scenarios.

The TRANSCOOP demonstrator system gives hints on the limitations of the approach taken in the project and points to open research problems. Two problems are recognized:

• the complexity of commutativity specifications and the consistency between the different commutativity rules,

CONCLUSIONS 197

• an adequate end-user interface that is not based on the selection of history entries (as in the current demonstrator)

The first problem is a rather theoretical problem of correct commutativity specifications which has partly been addressed in the work on the specification environment. However, the commutativity specifications used in the demonstrator were based on the implementor's knowledge instead of being generated by a tool. Due to the fact that the semantics of a method is difficult to capture formally, and due to the complexity of the backward and forward commutativity definitions (see [Klingemann et al., 1996]), such a tool remains an open research issue. Our ongoing work in this area is outlined in Section 9.4.

The second problem could be solved for particular application domains by specifying a mapping between the data presented to the user and the entries in the history. Such a mapping might rule out some exchange options but would increase the applicability for end-user cooperations. The CoCoA data exchange operations address this problem by predefining queries that select history entries to be exchanged. However, conflict resolution between those operations already executed in a workspace and those operations to be imported is not addressed in CoCoA.

A disadvantage of the history merging approach becomes evident when one considers scalability. The TRANSCOOP demonstrator system proved effective for cooperation involving a few users, but typical production workflow systems, for example, involve the cooperation of hundreds of users [Alonso, 1997]. It is not clear how well the history merging approach, or indeed the notion of private (yet visible) workspace histories fares in this context.

9.4 EXTENSIONS TO THE SPECIFICATION ENVIRONMENT

For the specification environment of the TRANSCOOP demonstrator, we concentrated our implementation efforts on (i) tool support for the simulation and analysis of the organizational view of a scenario, and (ii) tool support for the automated analysis of proof obligations for the commutativity relations used by the COACT transaction model. The first of these implementation efforts is described in Chapter 8. The second implementation effort proved to be more difficult than we anticipated, and it was not completed within the time frame of the project. However, our preliminary investigation of this problem led to a promising approach that we are continuing to work on.

During the final year of the TRANSCOOP project, we began using the TM proof tool to study the semantics-based commutativity relations required by the cooperative transaction model. The TM proof tool is an automated analysis technique that uses the Isabelle theorem prover [Paulson, 1990, Paulson, 1994] to statically investigate TM transaction safety with respect to database integrity constraints. An early version of the tool is described in [Spelt, 1995]. The TM proof tool is still under development at the University of Twente. As part of the verification technique, the database structure and method definitions of a TM database schema are translated to expressions in higher order


logic (HOL). The proof obligations for commutativity are then defined as expressions in HOL, and given to the Isabelle theorem prover for automated proof assistance. This technique proved to be promising [Even and Spelt, 1997] and is a topic of ongoing research.

9.5 LESSONS FOR TRANSACTION MANAGEMENT RESEARCH AND DEVELOPMENT

There was disagreement when planning the TRANSCOOP project that the goal of the project should be to develop transaction models for cooperative applications, rather than a single transaction model. At that time, the single model, although "adjustable", was left as a goal. The results gained in the TRANSCOOP project have made it more evident that there is no single transaction model that would support all applications-even in the CSCW field-in the same sense that the RjW model (see Chapter 3 for a detailed treatment of the R/W model) supports administrative applications. The same view has been represented also by other researchers and for example, customizable transaction models have been suggested as a solution [Georgakopoulos et al., 1996]. It seems to really be the case that different cooperative applications require different kinds of transactional support, where any of the ACID properties might need to be redefined. In an ultimate case, different parts of the same workflow might need different kinds of transactional properties. What are transactional properties? We consider a transaction model to address the correctness of concurrent computations that handle persistent, shared data in a failure-prone environment. Such a model defines syntax for the computations (e.g., a R/W sequence, a transaction tree, etc.) and some variant of generalized ACID properties for the interleavings of individual transactions (see Chapter 3).

One of the main conclusions of the research presented here is that one must continue the development of transactional frameworks. A simple transactional framework consists of a specification environment where scenario designers can design and verify transactional scenarios with suitable tools, and of a run-time environment, which executes the specifications and guarantees the transactional properties, as defined in a particular transaction model. Of course, compilers or interpreters are needed between these two parts and they are an essential part of the framework.

In the TRANSCOOP project, a particular transactional framework was implemented where the transaction model was fixed to be COACT and the specification language CoCoA contained features needed to express the concepts in this particular model. The run-time system supporting COACT was implemented by programming it fully manually. Evidently, this kind of approach is not feasible if many models are needed, unless the run-time system can be customized to support different kinds of transaction models.

A more complicated transactional framework, a kind of meta-level transactional framework should support indeed specification of different transaction models, and also at least semi-automatic generation of the run-time environ-

CONCLUSIONS 199

ments to support a particular transaction model. It should also support the specification of individual transactions obeying a particular model and their execution. A requirement for such an environment, which goes clearly beyond a simple framework, is the availability of tools to check the compatibility of different transaction models. This is important in cases where the same computation can use different models in different parts, or the same data can be accessed by transactions obeying different transaction models. These issues are for further research.

Based on our insight gained in the TRANSCOOP project, one can say that in a transactional framework there are at least two ingredients that seem to be important, and for which analyzing tools should be further developed. One ingredient is the commutativity of operations, as discussed above. Another is compensation as a backward recovery method. It was found useful in several applications we analyzed and it has also been used in the COACT model. Currently, there is no comprehensive formal theory on compensation and no clear understanding of what compensation means, when it can (or cannot) really be used, and how difficult compensation is to specify. Although not formally proven, it seems that it is impossible to automatically generate compensating operations at least for the most complicated definitions of compensation. The R/W model is, however, simple enough to allow the definition of algorithms that generate the compensating operations based on the history (see Chapter 3). The tools in a transactional environment should help to specify and analyze compensation properly.

In short, further research on transactional frameworks is challenging and requires high expertise and close cooperation of language specialists, transaction management specialists, software engineers, experts of formal specification approaches, and application specialists. Although it is a difficult task, we expect to see functioning and integrated transactional frameworks at the beginning of the next millennium.

References

[Abbot and Sarin, 1994] Abbot, K. R. and Sarin, S. K. (1994). Experiences with workflow management: Issues for the next generation. In Proceedings ACM 1994 Conference on Computer Supported Cooperative Work (CSCW '94), pages 113-120, Chapel Hill, North Carolina.

[Alonso, 1997] Alonso, G. (1997). TransCoop Workshop on Extending Data Management for Cooperative Work. Panel Discussion, June 6, 1997.

[Alonso et al., 1996] Alonso, G., Agrawal, D., El-Abbadi, A., Kamath, M., GiinthOr, R., and Mohan, C. (1996). Advanced transaction models in workflow contexts. In Proceedings of the 12th International Conference on Data Engineering (ICDE'96), pages 574-583, New Orleans, Louisiana. IEEE Computer Society.

[Anfindsen, 1997] Anfindsen, O. J. (1997). Apotram: An Application-Oriented Transaction Model. PhD thesis, University of Oslo, Department of Informatics.

[Ansari et al., 1992] Ansari, M., Ness, L., Rusinkiewicz, M., and Sheth, A. (1992). Using flexible transactions to support multi-system telecommunication applications. In Proceedings of the 18th International Conference on Very Large Databases, pages 65-76, Vancouver, Canada.

[Astrahan et al., 1976] Astrahan, M., Blasgen, M., Chamberlin, D., Eswaran, K., Gray, J. N., Griffiths, P., King, W., Lorie, R. A., McJones, P. R., Mehl, J. W., Putzolu, G. R., Traiger, I. L., Wade, B. W., and Watson, V. (1976). System R: A Relational Approach to Database Management. ACM Transactions on Database Systems, 1(2).

[Attie et al., 1993] Attie, P. C., Rusinkiewicz, M., Sheth, A., and Singh, M. P. (1993). Specifying and enforcing intertask dependencies. In Proceedings of the 19th International Conference on Very Large Databases, pages 134-145, Dublin, Ireland.

201


[Badrinath and Ramamritham, 1992] Badrinath, B. R. and Ramamritham, K. (1992). Semantic-based concurrency control: Beyond commutativity. ACM Transactions on Database Systems, 17(1): 163-199.

[Bal et al., 1996] Bal, R., Balsters, H., de By, R. A., Bosschaart, A., Flokstra, J., van Keulen, M., Skowronek, J., and Termorshuizen, B. (1996). The TM Manual, version 2.0, revision f. Technical Report IMPRESS JUT -TECH-T79-001-R2, University of Twente, Enschede, The Netherlands.

[Balsters et al., 1993] Balsters, H., de By, R. A., and Zicari, R. (1993). Typed sets as a basis for object-oriented database schemas. In Nierstrasz, O. M., editor, Proceedings of the Seventh European Conference on Object-Oriented Programming, volume 707 of Lecture Notes in Computer Science, pages 161-184, Kaiserslautern, Germany. Springer Verlag.

[Bancilhon et al., 1985] Bancilhon, F., Kim, W., and Korth, H. (1985). A model of CAD transactions. In Proceedings of the 11th International Conference on Very Large Databases, pages 25-33, Stockholm, Sweden.

[Bapat et al., 1996a] Bapat, A., Lohr, M., and Wasch, J. (1996a). Hypermedia support for the integrated systems engineering environment MUSE. In Proceedings of the Fifth International Conference on Data and Knowledge Systems in Manufacturing and Engineering (DKSME '96). Phoenix, Arizona.

[Bapat et al., 1996b] Bapat, A., Wasch, J., Aberer, K., and Haake, J. M. (1996b). HyperStorM: An extensible object-oriented hypermedia engine. In Proceedings of the Seventh ACM Conference on Hypertext (HYPERTEXT'96), pages 203-214. Washington, D.C.

[Beeri et al., 1989] Beeri, C., Bernstein, P. A., and Goodman, N. (1989). A model for concurrency in nested transactions systems. Journal of the ACM, 36(2) :230-269.

[Beeri et al., 1983] Beeri, C., Bernstein, P. A., Goodman, N., Lai, M. Y., and Shasha, D. E. (1983). A concurrency control theory for nested transactions. In Proceedings of the Second ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing.

[Bernstein et al., 1987] Bernstein, P. A., Hadzilacos, V., and Goodman, N. (1987). Concurrency Control and Recovery in Database Systems. AddisonWesley Publishing Company.

[Bernstein and Newcomer, 1997] Bernstein, P. A. and Newcomer, E. (1997). Principles of Transaction Processing for the Systems Professional. The MKP Series in Data Management Systems. Morgan Kaufmann Publishers, Inc.

[Biliris et al., 1994] Biliris, A., Dar, S., Gehani, N., Jagadish, H. V., and Ramamritham, A. (1994). Asset: A system for supporting extended transactions. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 44-54, Minneapolis, Minnesota.

REFERENCES 203

[Birman et al., 1991] Birman, K. P., Schiper, A., and Stephenson, P. (1991). Leightweight causal and atomic group multicast. ACM Transactions on Computer Systems, 9(3):272-314.

[Bjork, 1973] Bjork, L. A. (1973). Recovery scenarios for a DB/DC system. In Proceedings of the 28th ACM Annual Conference, pages 142-146. Atlanta.

[B6hm and Aberer, 1994] B6hm, K. and Aberer, K. (1994). An ObjectOriented Database Application for HyTime Document Structure. In Third International Conference on Information and Knowledge Management.

[Boll et al., 1996] Boll, S., Klas, W., and L6hr, M. (1996). Integrated database services for multimedia presentations. In Chung, S. M., editor, Multimedia Information Storage and Management. Kluwer Academic Publishers.

[Boll and Wasch, 1996] Boll, S. and Wasch, J. (1996). A Java Application Programming Interface to a Multimedia Enhanced Object-Oriented DBMS. In Proceedings of the First International Workshop on Persistence and Java (PJ1), Glasgow, Scotland.

[Bolognesi and Brinksma, 1987] Bolognesi, T. and Brinksma, E. (1987). Introduction to the ISO Specification Language LOTOS. Computer Networks and ISDN Systems, 14:25-59.

[Bond and Ricci, 1992] Bond, A. H. and Ricci, R. J. (1992). Cooperation in aircraft design. Research in Engineering Design, 4:115-130.

[Breitbart et al., 1993] Breitbart, Y., Deacon, A., Schek, H.-J., Shet, A., and Weikum, G. (1993). Merging application-centric and data-centric approaches to support transaction-oriented multi-system workflows. ACM SIGMOD Record, 22(3):23-30.

[Breitbart et al., 1991] Breitbart, Y., Georgakopoulos, D., Rusinkiewicz, M., and Silberschatz, A. (1991). On rigorous transaction scheduling. IEEE Transactions on Software Engineering, 17(9):954-960.

[Brodie and Stonebraker, 1995] Brodie, M. and Stonebraker, M. (1995). Migrating Legacy Systems-Gateways, Interfaces f3 the Incremental Approach. Morgan Kaufmann Publishers, Inc.

[Buchmann et al., 1992] Buchmann, A., Ozsu, T., Hornick, M., Georgakopoulos, D., and Manola, F. A. (1992). A transaction model for active distributed objects systems. In [Elmagarmid, 1992]' chapter 5, pages 123-158.

[Bukhres and Elmagarmid, 1996] Bukhres, O. A. and Elmagarmid, A. K., editors (1996). Object-oriented Multi-database Systems. Prentice-Hall.

[Cardelli and Wegner, 1985] Cardelli, L. and Wegner, P. (1985). On understanding types, data abstraction, and polymorphism. Computing Surveys, 17(4):471-522.

[Chrysanthis and Ramamritham, 1990] Chrysanthis, P. K. and Ramamritham, K. (1990). ACTA: A framework for specifying and reasoning about transaction structure and behavior. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 194-203, Atlantic City, New Jersey.


[Chrysanthis and Ramamritham, 1992] Chrysanthis, P. K. and Ramamritham, K. (1992). ACTA: The saga continues. In [Elmagarmid, 1992], chapter 10, pages 349-397.

[Chrysanthis and Ramamritham, 1993] Chrysanthis, P. K. and Ramamritham, K. (1993). Delegation in ACTA to control sharing in extended transactions. IEEE Data Engineering Bulletin, 16(2):16-19.

[Chrysanthis and Ramamritham, 1994] Chrysanthis, P. K. and Ramamritham, K. (1994). Synthesis of extended transaction models using ACTA. ACM Transactions on Database Systems, 19(3):450-491.

[Davies, 1973] Davies, C. T. (1973). Recovery semantics for a DB/DC system. In Proceedings of the 28th ACM Annual Conference, pages 136-141. Atlanta.

[Davies, 1978] Davies, C. T. (1978). Data processing spheres of control. IBM Systems Journal, 17(2).

[Dayal et al., 1990] Dayal, U., Hsu, M., and Ladin, R. (1990). Organizing longrunning activities with triggers and transactions. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 204-214, Atlantic City, New Jersey.

[Dayal et al., 1991] Dayal, U., Hsu, M., and Ladin, R. (1991). A transaction model for long-running activities. In Proceedings of the 17th International Conference on Very Large Databases, Barcelona, Spain.

[de By et al., 1996] de By, R., Lehtola, A., Pihlajamaa, 0., Veijalainen, J., and Wasch, J. (1996). Deliverable 111.2: Specification of the TRANSCOOP Demonstrator. Report TC/REP/VTT/D3-2/960425, Esprit Project No. 8012.

[de By et al., 1995a] de By, R. A., Even, S. J., and Verkoulen, P. A. C. (1995a). Functionally specified distributed transactions in co-operative scenarios. In Proceedings of RIDE-DOMS, pages 116-121, Taipei, Taiwan.

[de By et al., 1995b] de By, R. A., Lehtola, A., Pihlajamaa, 0., Veijalainen, J., and Wasch, J. (1995b). Deliverable III.1: Specification of the TRANSCOOP Reference Architecture. Report TC/REP/VTT/D3-1, Esprit Project No. 8012.

[Dittrich et al., 1987] Dittrich, K. R., Gotthard, W., and Lockemann, P. C. (1987). DAMOKLES-The Database System for the UNIBASE Software Engineering Environment. IEEE Database Engineering, 1O(1).

[Ellis and Gibbs, 1989] Ellis, C. A. and Gibbs, S. J. (1989). Concurrency control in groupware systems. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 399-407. MCC, Austin, Texas. Portland, Oregon.

[Ellis et al., 1991] Ellis, C. A., Gibbs, S. J., and Rein, G. L. (1991). Groupware: Some issues and experiences. Communications of the ACM, 34(1):38-58.

REFERENCES 205

[Elmagarmid,1992] Elmagarmid, A. K., editor (1992). Database Transaction Models for Advanced Applications. ACM Press. Morgan Kaufmann Publishers, Inc.

[Elmagarmid et al., 1990] Elmagarmid, A. K., Leu, Y., Litwin, W., and Rusinkiewicz, M. (1990). A Multi-database Transaction Model for InterBase. In Proceedings of the 16th International Conference on Very Large Databases, pages 507-518. Brisbane, Australia.

[Elmagarmid et al., 1992] Elmagarmid, A. K., Leu, Y., Mullen, J. G., and Bukhres, O. (1992). Introduction to advanced transaction models. In [EImagarmid, 1992], chapter 1, pages 1-32.

[Eswaran et al., 1976] Eswaran, K. P., Gray, J. N., Lorie, R. A., and Traiger, I. L. (1976). The notion of consistency and predicate locks in a database system. Communications of the ACM, 19(11):624-633.

[Even and Faase, 1994] Even, S. and Faase, F. (1994). Deliverable IV.l: Merge Options for LOTOS and TM. Report TC/REP/UT/D4-1/009, Esprit Project No. 8012.

[Even et al., 1996a] Even, S., Faase, F., Kaijanranta, H., Klingemann, J., Lehtola, A., Pihlajamaa, 0., Tesch, T., and Wasch, J. (1996a). Deliverable VIl.l: Design of the TRANSCOOP Demonstrator System. Report TC/REP /GMD/D7-1/704, Esprit Project No. 8012.

[Even and Spelt, 1997] Even, S. and Spelt, D. (1997). Formal specification of commutativity relations based on transaction semantics. 18pp. Draft document in preparation.

[Even et al., 1996b] Even, S. J., Faase, F. J., and de By, R. A. (1996b). Language features for cooperation in an object-oriented database environment. International Journal of Cooperative Information Systems, Special Issue on Formal Methods, 5(4):469-500.

[Even et al., 1996c] Even, S. J., Faase, F. J., Pihlajamaa, 0., and de By, R. A. (1996c). Deliverable IVA: Design of the TransCoop Specification Environment. Report TC /REP JUT /D4-4/032, Esprit Project No. 8012.

[Faase et al., 1996] Faase, F. J., Even, S. J., and de By, R. A. (1996). Deliverable IV.3: An introduction to CoCoA. Report TC /REP JUT /D4-3 /033, Esprit Project No. 8012.

[Faase et al., 1997] Faase, F. J., Even, S. J., de By, R. A., and Apers, P. M. G. (1997). Integrating organisational and transactional aspects of cooperative activities. In Cluet, S. and Hull, R., editors, Proceedings of the Sixth International Workshop on Database Programming Languages (DBPL), Estes Park, Colorado. To appear.

[Farrang and Ozsu, 1989] Farrang, A. A. and Ozsu, M. T. (1989). Using semantic knowledge of transactions to increase concurrency. A CM Transactions on Database Systems, 14(4):503-525.


[Fernandez and Zdonik, 1989] Fernandez, M. F. and Zdonik, S. B. (1989). Transaction groups: A model for controlling cooperative transactions. In Proceedings of the International Workshop on Persistent Object Systems, pages 341-350. Newcastle, New South Wales.

[Flokstra and Boon, 1996] Flokstra, J. and Boon, R. (1996). The TM Abstract Machine (TAM). Internal working document, University of Twente, Enschede, The Netherlands.

[Frohlich and Werner, 1994] Frohlich, M. and Werner, M. (1994). The Graph Visualization System da Vinci-A User Interface for Applications. Technical Report 5/94, Department of Computer Science, Universitat Bremen.

[Futatsugi et al., 1985] Futatsugi, K., Goguen, J., Jouannaud, J.-P., and Meseguer, J. (1985). Principles of OBJ2. In Reid, B. K., editor, Proceedings of the 12th ACM Symposium on Principles of Programming Languages, pages 52-66.

[Garcia-Molina,1983] Garcia-Molina, H. (1983). Using semantic knowledge for transaction processing in a distributed database. A CM Transactions on Database Systems, 8(2):186-213.

[Garcia-Molina et al., 1990] Garcia-Molina, H., Gawlick, D., Klein, J., Kleisner, K., and Salem, S. (1990). Coordinating multi-transaction activities. Technical Report CS-TR-247-90, University of Maryland.

[Garcia-Molina and Salem, 1987] Garcia-Molina, H. and Salem, K. (1987). Sagas. In Proceedings of the ACM SIGMOD Conference on Management of Data.

[Geller et al., 1991] Geller, J., Perl, Y., and Neuhold, E. J. (1991). Structural schema integration in heterogeneous multi database systems using the dual model. In Proceedings of the First IEEE International Workshop on Interoperability in Multidatabase Systems, pages 200-203, Kyoto, Japan.

[Georgakopolous et al., 1994] Georgakopolous, D., Hornick, M., Krychniak, P., and Manola, F. (1994). Specification and management of extended transactions in a programmable transaction environment. In Proceedings of the 10th IEEE International Conference on Data Engineering, pages 462-473, Houston, Texas.

[Georgakopoulos et al., 1996] Georgakopoulos, D., Hornick, M., and Manola, F. (1996). Customizing transaction models and mechanisms in a programmable environment supporting reliable workflow automation. IEEE Trans. on Knowledge and Data Engineering, 8(4):630-649.

[Georgakopoulos et al., 1993] Georgakopoulos, D., Hornick, M. F., Manola, F., Brodie, M. L., Heiler, S., Nayeri, F., and Hurwitz, B. (1993). An extended transaction environment for workflows in distributed object computing. IEEE Data Engineering Bulletin, 16(2):24-27.

[GMD-IPSI, 1995] GMD-IPSI (1995). VODAK V4.0 User Manual. Arbeitspapiere der GMD 910, Technical Report, GMD.

REFERENCES 207

[Gray and Reuter, 1993] Gray, J. and Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers, Inc.

[Greif and Sarin, 1987] Greif, I. and Sarin, S. (1987). Data sharing in group work. ACM Transactions on Office Information Systems, 5(2):187-211.

[Haake, 1995] Haake, J. (1995). Autorensysteme fur die kooperative Erstellung von Hypermedia-Dokumenten. PhD thesis, Technical University of Darmstadt.

[Haake and Wilson, 1992] Haake, J. M. and Wilson, B. (1992). Supporting collaborative writing of hyperdocuments in SEPIA. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, pages 138-146, Toronto, Canada.

[Halasz, 1988] Halasz, F. G. (1988). Reflection on Notecards: Seven issues for the next generation of hypermedia systems. Communications of the ACM, 31(7):836-852.

[Hannemann and Thiiring, 1993] Hannemann, J. and Thiiring, M. (1993). Schreiben als designproblem: Kognitive grundlagen einer hypertext autorenumgebung. K ognitionswissenschaft.

[Hayes, 1993] Hayes, I., editor (1993). Specification Case Studies. International Series in Computer Science. Prentice-Hall, Hemel-Hempstead, Hertfordshire, Great Britain, second edition.

[Hayes and Flowers, 1986] Hayes, J. R. and Flowers, L. (1986). Writing research and the writer. American Psychologist, 41(10):1106-1113.

[Herlihy, 1990] Herlihy, M. (1990). Apologizing versus asking permission: Optimistic concurrency control for abstract data types. ACM Transactions on Database Systems, 15(1):96-124.

[Herlihy, 1986] Herlihy, M. P. (1986). Optimistic concurrency control for abstract data types. In Proceedings of the Fifth A CM Symposium on Principles of Distributed Computing.

[Hollingsworth, 1994] Hollingsworth, D. (1994). Workflow Reference Model. Technical Report TCOO-1003 (Draft 1.1), Workflow Management Coalition.

[Honda, 1988] Honda, M. (1988). Support for parallel development in the Sun network software environment. In Proceedings of the Second International Workshop on Computer-Aided Software Engineering, pages 5-5-5-7, Cambridge, Massachusetts.

[Hunt and Rosenkrantz, 1979] Hunt, H. B. and Rosenkrantz, D. (1979). The complexity of testing predicate locks. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 127-133.

[ISO, 1987] ISO (1987). ISO 8807: Information Processing Systems-Open Systems Interconnection-LOTOS-A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour. International Standards Organization, Geneva, Switzerland, first edition.


[Johnson, 1994] Johnson, P. M. (1994). Experiences with EGRET: An exploratory group work environment. Collaborative Computing, 1(1}.

[Juopperi et al., 1995] Juopperi, J., Lehtola, A., Pihlajamaa, 0., Sladek, A., and Veijalainen, J. (1995). Usability of some workflow products in an interorganizational setting. In Proc. of IFIP WG8.1 Working Conference on Information Systems for Decentralized Organizations, Trondheim, Norway.

[Kaiser, 1995] Kaiser, G. E. (1995). Cooperative transactions for multi-user environments. In [Kim, 1995], chapter 20, pages 409-433.

[Kaiser and Feiler, 1987] Kaiser, G. E. and Feiler, P. H. (1987). Intelligent assistance without artificial intelligence. In Proceedings of the 92th IEEE Computer Society International Conference, pages 236-241, San Francisco, California.

[Kaiser et al., 1989] Kaiser, G. E., Perry, D. E., and Schell, W. M. (1989). Infuse: Fusing integration test management with change management. In Proceedings of the 19th IEEE Computer Software and Applications Conference, pages 552-558, Orlando, Florida.

[Kaiser and Pu, 1992] Kaiser, G. E. and Pu, C. (1992). Dynamic restructuring of transactions. In [Elmagarmid, 1992], chapter 8, pages 265-295.

[Kappel et al., 1995] Kappel, G., Prim, B., Rausch-Schott, S., and Retschitzegger, W. (1995). TriGS/low-active object-oriented workflow management. In Proceedings of the 29th Hawaii International Conference on System Sciences HICSS'95.

[Katz, 1990] Katz, R. H. (1990). Towards a unified framework for version modelling in engineering databases. ACM Computing Surveys, 22(4}.

[Kim, 1995] Kim, W., editor (1995). Modern Database Systems: The Object Model, Interoperability, and Beyond. Addison-Wesley Publishing Company.

[Kim and Lochovsky, 1989] Kim, W. and Lochovsky, F. H., editors (1989). Object-Oriented Concepts, Databases, and Applications. ACM Press.

[Klahold et al., 1985] Klahold, P., Schlageter, G., Unland, R., and Wilkes, W. (1985). A transaction model supporting complex applications in integrated information systems. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 388-401, Austin, Texas.

[Klas et al., 1994a] Klas, W., Aberer, K., and Neuhold, E. J. (1994a). Objectoriented modelling for hypermedia systems using the VODAK modelling language (VML). In Dogac, A., Oszu, T., Biliris, A., and Sellis, T., editors, Advances in Object-Oriented Database Systems, NATO ASI Series, pages 389-443. Springer Verlag.

[Klas et al., 1994b] Klas, W., Fischer, G., and Aberer, K. (1994b). Integrating a Relational Database System into VODAK using its Metaclass Concept. Journal of Systems Integration, 4(4}.

REFERENCES 209

[Klas and Schrefl, 1995] Klas, W. and Schrefl, M. (1995). Metaclasses and Their Application-Data Model Tailoring and Database Integration, volume 943 of Lecture Notes in Computer Science. Springer Verlag.

[Klein, 1991] Klein, J. (1991). Advanced rule driven transaction management. In Proceedings of the 36th IEEE Computer Society International Conference, pages 562-567, San Francisco, California.

[Klingemann et aI., 1995] Klingemann, J., Puustjarvi, J., Tesch, T., and VeijaIainen, J. (1995). Deliverable V.1: Analysis of Extensions and Adaptions of the Open-Nested Transaction Model. Report TC/REP /GMD/D5-1/507, Esprit Project No. 8012.

[Klingemann et aI., 1996] Klingemann, J., Tesch, T., and Wasch, J. (1996). Semantics-based transaction management for cooperative applications. In Proceedings of the International Workshop on Advanced Transaction Models and Architectures, Goa, India.

[Klingemann et aI., 1997] Klingemann, J., Tesch, T., and Wasch, J. (1997). Enabling cooperation among disconnected mobile users. In Proceedings of the Second International Conference on Cooperative Information Systems (CoopIS).

[Korth, 1983] Korth, H. F. (1983). Locking primitives in a database system. Journal of the ACM, 30(1):55-79.

[Korth et aI., 1990] Korth, H. F., Levy, E., and Silberschatz, A. (1990). A formal approach to recovery by compensating transactions. In Proceedings of the 16th International Conference on Very Large Databases, pages 95-106, Brisbane, Australia.

[Korth and Speegle, 1994] Korth, H. F. and Speegle, G. (1994). Formal aspects of concurrency control in long-duration transaction systems using the NT/PV model. ACM Transactions on Database Systems, 19(3).

[Kuo, 1996] Kuo, D. (1996). Model and verification of data manager based on ARIES. ACM Transactions on Database Systems, 21(4):427-479.

[Lamb and Landis, 1991] Lamb, C. and Landis, G. (1991). The ObjectStore Database System. Communications of the ACM, 34(11):32-39.

[Lawrence, 1997] Lawrence, P., editor (1997). Workflow Handbook 1997. John Wiley & Sons.

[Leymann and Altenhuber, 1994] Leymann, F. and Altenhuber, W. (1994). Managing business pr.ocesses as an information resource. IBM Systems Journal, 33(2).

[Lynch et aI., 1994] Lynch, N., Merrit, M., Weihl, W., and Fekete, A. (1994). Atomic Transactions. Morgan Kaufmann Publishers, Inc.

[Lynch, 1983] Lynch, N. A. (1983). Multilevel Atomicity-A New Correctness Criteria for Database Concurrency Control. A CM Transactions on Database Systems, 8(4).


[Manna and Pnueli, 1981] Manna, Z. and Pnueli, A. (1981). Verification of temporal programs: The temporal framework. In Boyer, R. S. and Moore, J. S., editors, The Correctness Problem in Computer Science. Academic Press, New York.

[Manola et aI., 1990] Manola, F., Heiler, S., Georgakopoulos, D., Hornick, M., and Brodie, M. {1990}. Distributed object management. International Journal of Intelligent and Cooperative Information Systems, 1{1}:1-41.

[March and Simon, 1958] March, J. G. and Simon, H. A. (1958). Organizations. New York.

[Martin and Ramamritham, 1997] Martin, C. P. and Ramamritham, K. {1997}. Delegation: Efficiently Rewriting History. In Proceedings of the 13th International Conference on Data Engineering (ICDE'97), Birmingham, England.

[MetaCase, 1996] MetaCase {1996}. MetaEdit+, Version 2.5 User's Guide. MetaCase Consulting, Jyvaskyla, Finland, first edition.

[Mitschang et aI., 1996] Mitschang, B., Harder, T., and Ritter, M. N. {1996}. Design management in CONCORD: Combining transaction management, workflow management and cooperation control. In Proceedings of the RIDE-Interoperability of Non-traditional Database Systems, pages 160-168, New Orleans, Louisiana.

[Mohan et aI., 1992] Mohan, C., Haderle, D., Lindsay, B., Pirahesh, H., and Schwarz, P. {1992}. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging. ACM Transactions on Database Systems, 17{1}.

[Moss, 1982] Moss, J. E. B. {1982}. Nested transactions and reliable distributed computing. In Proceedings of the IEEE Symposium on Reliability in Distributed Software and Database Systems.

[Muth et aI., 1992] Muth, P., Rakow, T. C., Klas, W., and Neuhold, E. J. {1992}. A transaction model for an open publication environment. In [EImagarmid, 1992], chapter 6, pages 159-218.

[Muth et aI., 1993] Muth, P., Rakow, T. C., Weikum, G., BrassIer, P., and Hasse, C. {1993}. Semantic concurrency control in object-oriented database systems. In Proceedings of the 9th IEEE International Conference on Data Engineering, pages 233-242. Vienna, Austria, April 19-20.

[Nelson, 1981] Nelson, T. (1981). Literary Machines. Mindful Press, CA.

[Neuhold and Thrau, 1992] Neuhold, E. J. and Thrau, V. {1992}. Database Research at IPSL SIGMOD RECORD, 21{1}:133-138.

[Ngu et aI., 1994] Ngu, A. H. H., Meersman, R., and Weigand, H. {1994}. Specification and verification of communication constraints for interoperable transactions. International Journal of Cooperative Information Systems, 3{1}.

REFERENCES 211

[Ngwenyama and Lyytinen, 1997] Ngwenyama, O. and Lyytinen, K. (1997). Groupware environments as action constitutive resources: A social action framework for analyzing groupware technologies. Computer supported Cooperative Work: The Journal of Collaborative Computing, 6(1):71-93.

[Nodine et al., 1992] Nodine, M. H., Ramaswamy, S., and Zdonik, S. B. (1992). A cooperative transaction model for design databases. In [Elmagarmid, 1992], chapter 3, pages 53-85.

[Nodine and Zdonik, 1990] Nodine, M. H. and Zdonik, S. B. (1990). Cooperative transaction hierarchies: A transaction model to support design applications. In Proceedings of the 16th International Conference on Very Large Databases, pages 83-94, Brisbane, Australia.

[Nodine and Zdonik, 1996] Nodine, M. H. and Zdonik, S. B. (1996). The impact of transaction management on object-oriented multi-database views. In [Bukhres and Elmagarmid, 1996], chapter 3, pages 57-104.

[ODP, 1995] ODP (1995). Draft Recommendation X.901: Reference Model for Open Distributed Processing, Part 1; Overview and 9uide to use. ISO/IEC JTC1/SC21/WG7.

[Papadimitriou,1986] Papadimitriou, C. H. (1986). The Theory of Database Concurrency Control. Computer Science Press, Rockville, Maryland.

[Paulson, 1990] Paulson, L. C. (1990). Isabelle: The next 700 theorem provers. In Odifreddi, P., editor, Logic and Computer Science, pages 361-386. Academic Press.

[Paulson, 1994] Paulson, L. C. (1994). Isabelle: A Generic Theorem Pmver, volume 828 of Lecture Notes in Computer Science. Springer Verlag.

[Prakash and Shim, 1994] Prakash, A. and Shim, H. S. (1994). Distview: Support for building efficient collaborative applications using replicated objects. In Proceedings of the Fifth Conference on Computer-Supported Cooperative Work, Chapel Hill, North Carolina.

[Pu et al., 1988] Pu, C., Kaiser, G. E., and Hutchinson, N. (1988). Splittransactions for open-ended activities. In Proceedings of the 14th International Conference on Very Large Databases, pages 26-37, Los Angeles, California.

[Pu and Leff, 1991] Pu, C. and Leff, A. (1991). Replica control in distributed systems: An asynchronous approach. In Proceedings of the ACM SIGMOD Conference on Management of Data, pages 377-386.

[Puustjarvi et al., 1997] Puustjarvi, J., Tirri, H., and Veijalainen, J. (1997). Reusability and modularity in transactional workfiows. Information Systems, 22(2/3):101-120.

[Rakowet al., 1996] Rakow, T. C., Klas, W., and Neuhold, E. J. (1996). Research on Multimedia Database Systems at GMD-IPSI. IEEE Multimedia Newsletter, 4(1):41-46.


[Ramamritham and Chrysanthis, 1997] Ramamritham, K. and Chrysanthis, P. K. (1997). Advances in Concurrency Control and Transaction Processing. IEEE CS Executive Briefing. IEEE Computer Society Press.

[Rastogi et al., 1993] Rastogi, R., Mehrotra, S., Breitbart, Y., Korth, H. F., and Silberschatz, A. (1993). On correctness of non-serializable executions. In Proceedings of the 12th ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, pages 97-108.

[Reed, 1978] Reed, D. P. (1978). Naming and Synchronization in a Decentralized Computer System. Ph.d. thesis, MIT, Computer Science Lab.

[Rensink, 1993] Rensink, A. (1993). Models and Methods for Action Refinement. PhD thesis, University of Twente, Enschede, The Netherlands.

[Reuter, 1989] Reuter, A. (1989). ConTracts: A means for extending control beyond transaction boundaries. In Proceedings of the Second International Workshop on High Performance Transaction Systems, Asilomar.

[Reuter and Wachter, 1991] Reuter, A. and Wachter, H. (1991). The ConTract model. IEEE Data Engineering Bulletin, 14(1):39-43.

[Ritter et al., 1994] Ritter, N., Mitschang, B., Harder, T., Gesmann, M., and SchOning, H. (1994). Capturing Design Dynamics-The CONCORD Approach. In Proceedings of the 10th IEEE International Conference on Data Engineering, pages 440-451, Houston, Texas.

[Rusinkiewicz et al., 1995] Rusinkiewicz, M., Klas, W., Tesch, T., Wasch, J., and Muth, P. (1995). Towards a cooperative transaction model: The cooperative activity model. In Proceedings of the 21st International Conference on Very Large Databases, pages 194-205. Zurich, Switzerland.

[Schwarz and Spector, 1984] Schwarz, P. M. and Spector, A. Z. (1984). Synchronizing shared abstract data types. ACM Transactions on Computer Systems, 2(3):223-250.

[Schwenkreis and Reuter, 1996] Schwenkreis, A. and Reuter, A. (1996). The impact of concurrency control on the programming model of contracts. In Proceedings of the First International Workshop on Advanced Transaction Models and Architectures.

[Schwenkreis, 1993] Schwenkreis, F. (1993). APRICOTS-A Prototype Implementation of a ConTract System-Management of the Control Flow and the Communication System. In Proceedings of the 12th Symposium on Reliable Distributed Systems. IEEE Computer Society Press.

[Sheth et al., 1996] Sheth, A., Georgakopoulos, D., Joosten, S., Rusinkiewicz, M., Scacchi, W., and Wileden, J. (1996). Report from the NSF Workshop on Workflow and Process Automation in Information Systems. Technical Report UGA-CS-TR-96-003, University of Georgia, Athens, Georgia.

[Simon, 1981] Simon, H. A. (1981). The Sciences of the Artificial. The MIT Press, Cambridge, Massachusetts.

REFERENCES 213

[Skarra, 1989) Skarra, A. H. (1989). Concurrency control for cooperating transactions in an object-oriented database. ACM SIGPLAN Notices, 24(4):145-147.

[Skarra and Zdonik, 1989) Skarra, A. H. and Zdonik, S. B. (1989). Concurrency control and object-oriented databases. In [Kim and Lochovsky, 1989), chapter 16, pages 395-421.

[Spelt, 1995) Spelt, D. (1995). A Proof Tool for TM. M.Sc. thesis, University of Twente, Enschede, The Netherlands.

[Streitz et al., 1992) Streitz, N., Haake, J., Hannemann, J., Lemke. A., Schuler, W., Schiitt, H., and Thiiring, M. (1992). SEPIA: A cooperative hypermedia authoring environment. In Proceedings of the Fourth ACM Conference on Hypertext, pages 11-22, Milano, Italy.

[Streitz et al., 1989) Streitz, N. A., Hannemann, J., and Thiiring, M. (1989). From ideas and arguments to hyperdocuments: Travelling through activity spaces. In Proceedings of the Second ACM Conference on Hypertext (Hypertext '89), pages 343-364, Pittsburgh, Pennsylvania.

[Siillow, 1994) Siillow, K. (1994). MultiMedia Forum-An Interactive Online Journal. In Hiiser, C., Mohr, W., and Quint, V., editors, Proceedings of Conference on Electronic Publishing, pages 413-422. John Wiley & Sons, Ltd.

[Tang and Veijalainen, 1995a) Tang, J. and Veijalainen, J. (1995a). Enforcing inter-task dependencies in transactional workflows. In Proceedings of the Third International Conference on Cooperative Information Systems. May 9-12, Vienna, Austria.

[Tang and Veijalainen, 1995b) Tang, J. and Veijalainen, J. (1995b). A formal method for the enforcement of inter-task dependencies in transactional workflows. Submitted for publication.

[Tang and Veijalainen, 1995c) Tang, J. and Veijalainen, J. (1995c). Transactionoriented workflow concepts in inter-organizational environments. In Proceedings of the Fourth International Conference on Information and Knowledge Management (CIKM-95), Baltimore, Maryland.

[Tesch and Verkoulen, 1995) Tesch, T. and Verkoulen, P. (1995). Deliverable II.2: Requirements for the TransCoop Transaction Model. Report TC /REP /GMD /D2-2/207, Esprit Project No. 8012.

[Tesch and Wasch, 1995) Tesch, T. and Wasch, J. (1995). Transaction support for cooperative hypermedia document authoring: A study on requirements. In Proc. of 8th ERCIM Database Research Group Workshop on Database Issues and Infrastructure in Cooperative Information Systems, pages 31-42, Trondheim, Norway.

[Thiiring et al., 1990) Thiiring, M., Hannemann, J., and Streitz, N. (1990). Schreiben als Designproblem: Ein integrativer Ansatz. In Frey, D., editor,


Bericht uber den 97. K ongress der Deutschen Gesellschaft fUr Psychologie, Gottingen.

[Tichy, 1985) Tichy, W. F. (1985). RCS: A system for version control. Software Practice and Experience, 15(7):637-654.

[TransCoop, 1994) TransCoop (1994). Transcoop: Transaction management support for cooperative applications. Technical Annex (project internal). Esprit Project 8012.

[Ullman, 1982) Ullman, J. D. (1982). Principles of Database Systems. Computer Science Press, Rockville, Maryland, 2nd edition.

[van der Aalst, 1997] van der Aalst, W. M. P. (1997). Verification of workflow nets. In Azema, P. and Balbo, G., editors, Application and Theory of Petri Nets, Lecture Notes in Computer Science. Springer Verlag, Berlin, Germany.

[Veijalainen, 1990) Veijalainen, J. (1990). Transaction Concepts in Autonomous Database Environments. Oldenburg-Verlag, Miinchen.

[Veijalainen, 1993) Veijalainen, J. (1993). Heterogeneous multi-level transaction management with multiple subtransactions. In Fourth Intl. Conference on Database and Expert Systems Applications, DEXA '99, volume 720 of Lecture Notes in Computer Science, pages 181-188. Springer Verlag.

[Veijalainen et aI., 1992) Veijalainen, J., Eliassen, F., and Holtkamp, B. (1992). The S-transaction Model. In [Elmagarmid, 1992), chapter 12, pages 467-513.

[Veijalainen and Wolski, 1992) Veijalainen, J. and Wolski, A. (1992). Prepare and commit certification for decentralized transaction management in rigorous heterogeneous multidatabases. In Proceedings of the 8th IEEE International Conference on Data Engineering, pages 470-479.

[Veijalainen and Wolski, 1997) Veijalainen, J. and Wolski, A. (1997). Transaction-based recovery. In Elmgarmid, A. K., Sheth, A., and Rusinkiewicz, M., editors, Heterogeneous Distributed Database Management, chapter 12. Morgan Kaufmann Publishers, Inc.

[Verkoulen and Tesch, 1995) Verkoulen, P. and Tesch, T. (1995). Deliverable II.1: Requirements for the TransCoop Specification Language. Report TCjREP JUT jD2-1j014, Esprit Project No. 8012.

[Verkoulen et al., 1995) Verkoulen, P. A. C., Faase, F. J., Selders, A. W., and Oude Egberink, P. J. J. (1995). Requirements for an advanced database transaction model to support Design for Manufacturing. In Proceedings of the Flexible Automation and Intelligent Manufacturing Conference, pages 102-113. Begell House, Inc. New York-Wallingford (U.K.). Stuttgart, Germany.

[Vingralek et al., 1997) Vingralek, R., Hasse, H., Breitbart, Y., and Schek, H.J. (1997). Unifying concurrency control and recovery of transactions with semantically rich operations. Journal of Theoretical Computer Science. To appear.

REFERENCES 215

[Vinter et al., 1986] Vinter, S., Ramamritham, K., and Stemple, D. (1986). Recoverable actions in Gutenberg. In Proceedings of the Sixth IEEE International Conference on Distributed Computing Systems, pages 242-249. Washington, D.C.

[Wachter and Reuter, 1990] Wachter, H. and Reuter, A. (1990). Grundkonzepte und realisierungsstrategien des contract-modells. Informatik Forschung und Entwicklung, 5:202-212.

[Wachter and Reuter, 1992] Wachter, H. and Reuter, A. (1992). The ConTract model. In [Elmagarmid, 1992], chapter 7, pages 219-264.

[Wachter, 1991] Wachter, W. (1991). Contracts: A means for improving reliability in distributed computing. In IEEE Computer Society International Conference.

(Walborn and Chrysanthis, 1995] Walborn, G. D. and Chrysanthis, P. K. (1995). Supporting semantics-based transaction processing in mobile database applications. In Proceedings of the 14th Symposium on Reliable Distributed Computing, Bad Neuenahr, Germany.

[Wasch and Aberer, 1995] Wasch, J. and Aberer, K. (1995). Flexible design and efficient implementation of a hypermedia document database system by tailoring semantic relationships. In Proceedings of the Sixth IFIP Conference on Database Semantics. Atlanta, Georgia.

[Wasch and Klas, 1996] Wasch, J. and Klas, W. (1996). History merging as a mechanism for concurrency control in cooperative environments. In Proceedings of RIDE-Interoperability of Nontraditional Database Systems, pages 76-85, New Orleans, Louisiana.

[Weihl, 1988] Weihl, W. E. (1988). Commutativity-based concurrency control for abstract data types. IEEE Transactions on Computers, 37(12):1488-1505.

[Weihl, 1989] Weihl, W. E. (1989). The impact of recovery on concurrency control. In Proceedings of the 8th ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, pages 259-269.

[Weihl, 1993] Weihl, W. E. (1993). The impact ofrecovery on concurrency control. Journal of Computer and System Sciences, 47:157-184.

(Weikum, 1991] Weikum, G. (1991). Principles and realization strategies of multi-level transaction management. ACM Transactions on Database Systems, 16(1):132-180.

[Weikum, 1993] Weikum, G. (1993). Extending transaction management to capture more consistency with better performance. In Proceedings of the 9th French Database Conference, Toulouse, France. Invited Paper.

[Weikum et al., 1993] Weikum, G., Deacon, A., Schaad, W., and Schek, H. (1993). Open nested transaction in federated database systems. IEEE Data Engineering Bulletin, 16:4-7.


[Weikum and Scheck, 1991] Weikum, G. and Scheck, H.-J. (1991). Multi-level transactions and open nested transactions. IEEE Data Engineering Bulletin, 14(1):60-64.

[Weikum and Schek, 1992] Weikum, G. and Schek, H.-J. (1992). Concepts and applications of multi-level transactions and open nested transactions. In [EImagarmid, 1992], chapter 13, pages 515-554.

[Wiil and Leggett, 1993] Wiil, U. K. and Leggett, J. J. (1993). Concurrency control in collaborative hypertext systems. In Proceedings of the Fifth ACM Conference on Hypertext, pages 14-18. Seattle, Washington.

[Wodtke and Weikum, 1997] Wodtke, D. and Weikum, G. (1997). A formal foundation for distributed workflow execution based on state charts. In Proceedings of the Sixth International Conference on Database Theory (ICDT'97), volume 1186 of Lecture Notes in Computer Science, Delphi, Greece. Springer Verlag.

[Wodtke et al., 1996] Wodtke, D., Weissenfels, J., Weikum, G., and Dittrich, A. K. (1996). The Mentor Project: Steps towards enterprise-wide workflow management. In Proceedings of the 12th IEEE International Conference on Data Engineering ICDE'96.

[Worah and Sheth, 1996] Worah, D. and Sheth, A. (1996). What do advanced transaction models have to offer for workflows? In International Workshop on Advanced Transaction Models and Architectures.

[Wordsworth, 1987] Wordsworth, J. B. (1987). A Z Development Method. Technical report, IBM United Kingdom Laboratories Ltd., Hursley Park.

[Workflow Management Coalition, 1995] Workflow Management Coalition (1995). Workflow Management Coalition Overview. Workflow Management Coalition Office, Avenue Marcel Thiry 204, 1200 Brussels, Belgium.

Index

Abort, 29, 31, 39, 41-42 cascading, 40, 49

Aborted completion, 36 ACT ONE, 19 ACTA,58 Activity space, 178 Activity

long-lasting, 16-17 Actor, 20, 23, 93, 96 Administrator, 94, 96 ADT theory, 19 Agent, 20, 23, 62, 94

fully automatic, 62 program, 98, 102 remote execution, 98, 103 user, 98, 102

Anomaly, Hi8, 170 concurrency, 29, 89 failure, 29

Application database, 184-186 Apricots, 104 Architecture, 94 Atomicity, 11, 149

fuzzy, 44 generalized, 42, 44, 50, 58 in ACID, 12, 22, 31-32, 41, 57 of subtransaction, 41 probabilistic, 44

Authorization information, 62 Backward recovery, 37, 43, 58

algorithm, 31 in workflow, 68

Begin-transaction, 29, 39 Behavior expression

in LOTOS, 19 Behavior-oriented approach, 150 Blind write, 168 CA,156 Calling hierarchy

of methods, 18

Case study, 14 CAT, 151, 153 CDA, 59, 88 Check_merge, 187, 190 CM, 112-113, 174-175, 184, 186, 188 CoAct, 149, 151, 173, 177, 179, 186-187

be, 153, 157 fe, 153, 161 Sinit, 156 S1-, 155 -<, 163 ~, 153

CoCoA paradigm, 118 actor, 118 communication operation, 119 cooperation, 118 data exchange operation, 119 data operation, 119 object base schema, 119 private workspace, 119 scenario, 118 shared workspace, 119 workspace, 118

CoCoA syntax, 143 CoCoA tool set, 138 CoCoA, 96, 117, 134, 150, 185, 188

procedure, 123-125 step, 123

Commit, 22, 29, 39, 41-42 Committed completion, 36 Committed projection, 35 Communicating processes, 116 Communication operation (also called

Communication), 122, 126 Commutativity relation

semantic, 17 Commutativity, 150, 152-153, 157, 161, 166,

169, 171, 180, 187 backward, 130, 150, 152-153, 157, 169

217


forward, 131, 150, 152-153, 161, 164-166, 187

of edit operations, 128 specification, 197 tables, 154

Compensatable, 160 Compensating actions

in workflow, 55, 68 Compensating activity, 90 Compensating operation, 46-47, 58 Compensation, 14, 37, 90, 153, 160, 164,

186-187, 191, 199 Compiler, 176, 188 Computation tree, 28 Computation, 27 Computational complexity, 38 Computer-Supported Cooperative Work, 11,

20,23 Concord, 95, 104 Concurrency control

optimistic, 40, 49 pessimistic, 40 semantics-based, 49

Concurrency, 11 Configuration, 52 Conflict, 17

detection principle, 30 detection, 46 equivalence, 35 specification, 58 table, 46

Consistency constraint, 17 dynamic,31 static, 31, 44

Consistency partition, 44 Consistency violation, 17 Consistency, 149

dynamic,30 in ACID, 12, 22, 30, 32, 34-35, 57 of a version set, 52

Consistent unit of work, 152, 157-158, 159, 165, 191

Constraint break-point, 122 termination, 122

ConTract model, 95, 104 Control flow

in workflow, 61 Cooperation manager, 174, 176, 184, 186,

188 Cooperation scenario

data sharing, 115-116 freedom of action/free-form style, 116,

118,126 organization, 115 role of specification, 116 rules of behavior, 116

spectrum, 118 Cooperation, 65, 149-150 Cooperative activity type, 150-151, 153 Cooperative activity, 20, 151, 153, 156, 185

abort, 152 commit, 151-152 start, 151-152

Cooperative Document Authoring, 23, 59, 118, 194

Cooperative scenario, 115, 150 Cooperative system

functionality of, 116 Cooperative transaction manager, 174, 177,

184, 186 Cooperative work, 12, 149 Coordination, 65 CORBA,95 CSCW, 11,20, 23, 193 CTM, 101, 112-113, 174-175, 184, 186-188,

190-191 Data exchange operation, 126 Data flow

in workflow, 62 Data item, 155 Data operation, 126, 135, 151, 153, 155, 186,

188, 191 execution, 151 instance, 151, 155 type, 151, 153

Data types, 62 Data

consistency, 90 permanent, 21 persistent, 18 private, 90 shared, 23, 90 uncommitted, 38 versioning, 90 volatile, 21

Database administrator, 61 Database Management System, 12, 16, 29

conventional, 16 Database state, 47

consistent, 30 Database System, 185

Object-oriented, 18, 185 Database transaction, 28 Database, 29

distributed, 40 private, 52 semi-public, 52

Da Vinci Graph Visualization Tool, 176 DBMS, 29, 81, 185-186 DBS, 98,100 Deadlock, 39 Decomposition

of commands, 33

Delegate, 152, 165, 187, 189 Delegation, 51 Design for Manufacturing, 23, 59-60, 118,

194 DfM, 59,88 Dirty data, 32 Document archive, 64 Document archiving system, 64 Domain, 155 DOMS,95 Durability

in ACID, 12, 22, 30, 32, 34, 37, 57 EDIFACT,103 EGUI, 175-176, 184, 189, 191 End-user role, 21 Environment

autonomous, 44 EP,100 Event notification (See also Communication

operation), 122 Event-condition-action rule, 127 Exchange operation, 152 Execution rule, 128-129, 132, 137

parallel specification, 129 Extended graphical user interface, 176, 184,

189 Finite-state automaton, 53 Finnish Telecom 101 Service, 70 FlowMark, 95, 108 Force_merge, 187, 191 Formal specification, 193 Formal techniques

use of, 115-116 Forward recovery, 43

in workflow, 68 Generalization/specialization hierarchy, 19 GraCoop, 124, 176 Group editor

synchronous, 53 Groupware system

real-time, 53 Groupware, 23 HAD, 65 History correctness, 130 History merging, 131, 150, 152, 155, 161,

163-164, 177, 185-186 algorithm, 163

History rule, 128, 130-131 History, 150-151, 156-159, 161-162,

186-187, 190 correct merged, 162 destination, 187, 190 entry, 186 exchange history, 163, 165 legal, 156 non-recoverable, 32 NP-complete, 38

polynomial, 38 PSPACE-complete, 38 recoverable, 40 reliable, 36, 38 rigorous, 38-39

INDEX 219

roll-back reliable, 38 semantically' consistent, 47 serial, 35 source, 187 subhistory, 156

closed, 158, 163 independent, 159, 163 minimal closed, 158, 163, 165, 187

Hyperdocument, 81, 83-84, 177 Hypermedia, 17, 80-81, 154, 175, 177

authoring, 175, 177 Hypertext, 154 Identifier, 155 Ignores, 167-168 Import, 152, 165, 187, 189 Individual work, 150, 179 Indivisible operation, 12 Interaction event, 123 Interaction point

entry, 123-125 exit, 123-125 interrupt, 123, 128 signal, 123, 128

Interoperation, 149 Isabelle theorem prover, 197-198 Isolation, 149

in ACID, 12, 22, 30, 32, 41, 57 of subtransaction, 41

Java, 177, 182, 186 Join command, 50 Joint work, 150 Legal, 156

history, 156 operation, 156

Lock predicate, 32 semantic, 50

Locking protocol, 18 Locking scheme, 22, 39

extended, 53 Locking, 39-40 Log, 38, 46 Logging, 22 LOTOS, 19-20, 116-117, 139, 141-142 LOTOS/TM, 11, 97,117,142,196 LTM,97 Media failure, 38 Merge alternatives, 165, 185 Mergeable, 161 Merging rules, 152-153 Meta-modeling, 16 Method, 17


Mobile environments, 185 Model

process algebraic, 19 MT, 98, 100 Multimedia, 16 Nested transaction, 41 Nodes in SEPIA

atomic,179 composite, 179

opening, 179 Nondeterminism, 19 Object-oriented database technology, 11 ObjectStore, 113, 185 OID,188 OMG,95 Open Distributed Processing, 94-95 Open nested transaction model, 45 Open Publication Environment, 106 Operation disabling, 126 Operation enabling, 123, 126-128

CoCoA syntax of, 126 Operation invocation pattern, 120 Operation lock, 39 Operation, 151, 155

communication, 21, 126, 188, 191 compensating, 18 conflict-free, 17 data exchange, 21, 123, 126, 128, 188, 191

export, 123 import, 123

data, 21, 122, 126, 135 intervening, 47 legal, 156 recoverable, 49

Organizational structure, 21 Organizational view, 99, 101 OSI

protocol specification, 19 service specification, 19

OSS, 100, 103 PA, 98, 102 Parallel step activation, 127 Parallelism, 19

inter-transactional, 41, 49 intra-transactional, 41, 45

Persistent data, 29 Phantom problem, 33 Predicate locking, 46 Process language, 21 Protocol

floor passing, 53 social, 53

R/W model, 27, 38, 198 Re-execution, 152, 164-166, 187 REA, 98, 103 Read/write model, 17,27 Reads-from relation, 34-36

Real-time requirements, 62 Recoverability, 12, 27, 167-168 Recovery, 54

algorithm, 38 backward, 31, 199 protocols, 22

Reference architecture, 93, 96 Relevant predecessor, 157 Reliability, 11-12

of history, 34 Request_work, 187 Role description, 62 Roll-back reliability

of history, 34 Run-time architecture, 184 Run-time environment, 113, 174, 176, 184,

186 Run-time system, 21 Save, 152, 187, 189 Scenario designer, 21, 96, 198 Scenario specification, 116, 134 Scenario state

active steps, 123 enabled interaction points, 123 transition, 123 users, 123

Scenario, 20-21, 23, 93 control flow, 121, 124, 138 organizational aspects, 119, 123

allowed operations, 119 steps, 119

termination, 125 transactional aspects, 120, 128

break-point constraints, 122 history constraints, 120 ordering constraints, 120 termination constraints, 120, 122

transition rule (See also Interaction point), 123-125

Security information, 62 Semantics-based transaction management,

150 SEPIA, 17, 60, 80-82, 112-113, 150, 154,

173,175-177,177-179,184,186,189 graphical user interface, 178 loosely coupled mode, 179 tightly coupled mode, 179

Serial forest, 45 Serializability graph checker, 40 Serializability graph, 35 Serializability, 12, 17, 22, 27, 34

conflict, 35 multi-level, 45 state, 44 view, 35

Serializable forest, 45 Shared resources

consistency of, 116 Specification database, 188 Specification environment, 21, 112, 173-175 Specification language, 21, 90, 194 Split command, 50 State transition, 30 State, 155-156

empty, 155 equivalent, 156

State-oriented approach, 150 Status database, 176, 185-186, 188 Step, 119, 173, 176, 185-186, 188, 191

activation, 123, 127 deactivation, 123, 127 parallel, 127

Subtransaction, 18, 41 committed, 18 compensating, 47, 50 contingency, 44 global, 41 local, 41

Subtree compensating, 43

System crash, 38 Termination constraint, 132-133, 137 Time-stamp, 39 TM Abstract Machine, 176, 182 TM, 20,112,116-117,134,141-142,

147-148, 197 TOS, 96-97, 99 Transaction boundary, 124 Transaction management system, 22

global,44 Transaction management, 193 Transaction manager

traditional, 30 Transaction model, 13-14, 20-22, 29, 58,

149, 173, 186 advanced, 14 cooperative, 18, 60, 90, 149, 186 open nested, 11, 13, 17-18 split /join, 50

Transaction program, 22, 29-30, 34 Transaction restart, 39 Transaction specification, 30, 57 Transaction tree, 41, 45, 198

global,44 Transaction, 12, 18, 22, 27

(formal) flat, 42 aborted, 31, 35 ACID,67 centralized, 40 committed, 31, 38 complete, 35 completion, 36 contingency, 69 distributed, 40, 43

global,41 incomplete, 35-36 nested, 45 open nested, 17 successful, 42 uncommitted, 48 unsuccessful, 42

Transactional

INDEX 221

framework, 57-58, 194, 198 framework

cooperative, 194 interface, 29-30 metamodeling environment, 58 property, 21, 28, 41 requirements, 13 support, 12 view, 99, 101 workflow, 124

TransCoop Demonstrator, 13, 173-175 CoCoA to CM Compiler, 176 CoCoA to CoAct Compiler, 176 Cooperation Manager, 176 Cooperative Transaction Manager, 177 Dynamic Analysis Tool, 176 Extended Graphical User Interface, 176 Graphical Scenario Editor, 124, 176 Static Analysis Tool, 176 Status Database, 176

TransCoop Reference Architecture, 93, 96 CoCoA2CMSpec Compiler, 97, 99 CoCoA2CTMSpec Compiler, 97, 99 CoCoA2LTM Compiler, 97, 99 Cooperation Manager, 99, 101 Cooperative Transaction Manager, 99, 101 Database System, 98, 100 External Program, 98, 100 Managing Tool, 98, 100 Object Server, 96-97, 99 Object Storage Server, 100, 103 Parser/Type-checker, 97-98 Program Agent, 98, 102 Remote Execution Agent, 98, 103 Run-time Environment, 96, 100 Simulation Environment, 97, 99 Specification Editor, 97-98 Specification Environment, 96, 98 Status Database, 101 Transaction Management Support

System, 97, 100 User Agent, 98, 102 User Interface, 98 Verification Toolbox, 97, 99

TRE, 96,100 TSE, 96, 98 TTMSS, 97, 100, 113 Two-phase commit protocol (2PC), 41 Two-phase locking (2PL), 39


UA, 98, 102 Uncommitted data, 38 User categories, 96 User group, 21 User role, 21, 188 Value transfer

between steps in CoCoA, 127 Verification tools, 58, 197 Version function, 36 Version history

of an object, 52 Version

alternative, 90 immutable, 52

VML,81 VODAK, 16-17, 81, 112-113, 175, 177-179,

184-185, 186, 188 architecture, 16 data dictionary, 18 data model of, 17 lock manager, 18 message handling in, 185 Modeling Language VML, 18 object buffer, 185 object management, 185 schema compiler, 18 storage manager, 185 transaction manager, 18

WfMC Administration and Monitoring Tools, 108 Invoked Applications, 108 Other Workflow Enactment Services, 108 Process Definition Tools, 108 Workflow Client Applications, 108 Workflow Reference Model, 108

Whiteboard shared,53

Work object, 23 Workflow Application Programming

Interface (WAPI), 108 Workflow Management Coalition (WfMC),

108 Workflow Management System, 64, 88 Workflow Systems, 59, 194 Workflow, 198

administrator, 63 applications, 23, 88, 118 backward recovery in, 68 compensating actions in, 68 control flow between steps, 61 data flow between steps, 62 designer, 61 forward recovery in, 68 performance analysis of, 66 private data in, 67 process instance, 62 process, 14 re-execution in, 68 resubmission in, 68 shared data in, 67 specification, 108 tractability of, 64 transactional properties of, 62 transactional, 54 trustworthiness of data in, 69

Workspace type, 135 Workspace, 150-151, 179, 184-186, 190

common, 119, 151 history, 128, 151, 157, 177, 179, 185-187 indentification, 123 initial state, 156 private, 151 realization, 184 semi-public, 52