transparent and flexible data sharing for synchronous groupware · preface synchronous groupware...

Transparent and Flexible Data Sharing for

Synchronous Groupware

Dissertation

zur Erlangung des Grades einesDoktors der Naturwissenschaftendes Fachbereichs Informatik der

FernUniversitat in Hagen

vorgelegt vonDipl.-Inform. Stephan Lukosch

Hagen, Mai 2003

Preface

Synchronous groupware allows users, who are geographically distributed, to collab-orate via a computer network. Currently, groupware is playing a major role indistance education, where it supports group discussions, joint work on electroniccourses, joint visits of Web pages, remote laboratories, video conferences, joint pro-gram development, cooperative publishing, virtual environments etc.

Developing groupware is a difficult and time-consuming task. To relieve develop-ers, a development platform can offer solutions for recurring problems, e.g. providefunctions for collaboration, communication, user interface development, and datahandling.

To collaborate, users must become able to coordinate their work, e.g. plan,schedule, and inform and get informed about joint sessions.

A groupware application has to communicate with other computers, i.e. com-munication links have to be established, data be transferred and connections besupervised.

In contrast to single-user applications, the user interface of a groupware appli-cation has to manage input and output from and to many users simultaneously;special group functions have to support collaboration awareness.

Groupware applications share and distribute data among geographically dis-tributed users; data must be kept consistent, concurrency control mechanisms mustbe used for coordinating parallel data modifications; users must be able to storeshared data, e.g. for reusing them in later synchronous sessions.

The wide range of synchronous groupware applications leads to quite differentrequirements on a development platform; it has to provide a variety of solutionsto choose from and even allow a developer to extend the platform with his ownsolutions.

This thesis mainly focuses on the specification, design and implementation ofa transparent development platform DreamObjects, that relieves developers fromall data sharing issues mentioned above. Developing a complex groupware applica-tion becomes almost as simple as developing a single-user application, i.e. devel-opers can concentrate on application-specific details and their reliable realization.DreamObjects offers a wide variety of standard solutions concerning data distri-bution and data consistency, but also allows a developer to individually adapt theplatform to her special requirements and needs.

Claus Unger

iii

iv PREFACE

Acknowledgements

Many people assisted me while working on this thesis. Without their support itwould have been much more strenuous to complete this thesis. I thank Prof. Dr.Claus Unger, as he gave me the opportunity to work on this thesis. Additionally,I thank him for his unrestricted support and his encouragement. Furthermore, Ithank Prof. Dr. Jorg M. Haake for his valuable advice in the final phase of thisthesis.

Moreover, I want to thank all my former and current teammates for discussions,feedback, criticism, and the mind-expanding lunch breaks. To avoid the nontrivialproblem of whom to mention first, these are in alphabetical order, Sonja Branskat,Peter Fasching, Dominic Heutelbeck, Dr. Daniela Keller, Christel Lehmann, BirgitLemken, Dr. Jorg Roth, Sibylle Schick, Daniel Weinand, and Dr. Dirk Westhoff.

I want to thank Dominic Heutelbeck for the interesting discussions that resultedfrom his different perspective on my work.

Daniela Keller not only carefully reviewed and constructively criticized this the-sis, but also earlier publications on which this thesis is based.

Special thanks are due to Christel Lehmann. She always had time to listen tomy problems and knew how to motivate me again.

As the door to Jorg Roth’s office was always open, I could step in and involve himin discussions. While some discussions were short, others were really long. However,at the end there was always a solution. Furthermore, he developed DreamTeam, thestarting point of this thesis.

Thanks are also due to Sibylle Schick. Every morning she cheerfully enters theinstitute and gives me the feeling that it is going to be a fine day.

Daniel Weinand implemented large parts of the collaborative virtual environ-ment. Apart from the functional core of the application, he always had time toimprove the appearance of the virtual environment. This really showed me that myplatform meets the stated requirements.

Without Dirk Westhoff, I possibly would never have started to work at theUniversity of Hagen. He motivated me to start a job at the University of Hagen,when he worked on his doctoral thesis and I was a student.

Last but not least, I have to thank my parents, my sister, my brother-in-law, mynephew, my niece, and Sandra. They always reminded me that there is life besidesthe work on the thesis. Without their help and support, it would never have beenpossible for me to finish this thesis.

Stephan Lukosch

v

vi ACKNOWLEDGEMENTS

Contents

Preface iii

Acknowledgements v

Contents vii

List of Figures xi

List of Tables xiii

Nomenclature xv

1 Introduction 1

1.1 Problem Statement and Approach . . . . . . . . . . . . . . . . . . . . 31.2 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . 5

2 System Requirements 7

2.1 DreamTeam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Requirements in the Data Domain . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Example Application . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Data Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.3 Data Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.4 Concurrency Control . . . . . . . . . . . . . . . . . . . . . . . 202.2.5 Data Persistency . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Related Work 27

3.1 Central State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Replicated State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Flexible State Distribution . . . . . . . . . . . . . . . . . . . . . . . . 353.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Approach 43

5 Notification service 47

5.1 Event-based Notification . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.1 Object-listener . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vii

viii CONTENTS

5.1.2 Call-listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Mapping-based Notification . . . . . . . . . . . . . . . . . . . . . . . 51

6 Concurrency Control 53

6.1 Object-based Concurrency Control . . . . . . . . . . . . . . . . . . . 536.2 Method-based Concurrency Control . . . . . . . . . . . . . . . . . . . 54

6.2.1 Intra-object Concurrency Control . . . . . . . . . . . . . . . . 556.2.2 Inter-object Concurrency Control . . . . . . . . . . . . . . . . 556.2.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3 Extensibility and Adaptability . . . . . . . . . . . . . . . . . . . . . . 586.3.1 Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3.2 Concurrency Control Schemes . . . . . . . . . . . . . . . . . . 59

7 Flat Distributed Actions 61

7.1 Object Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.1.1 Substitute Generation . . . . . . . . . . . . . . . . . . . . . . 627.1.2 Initialization and Configuration . . . . . . . . . . . . . . . . . 637.1.3 Object Creation and Distribution . . . . . . . . . . . . . . . . 65

7.2 Object Duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.3 Object Deregistration . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.4 Flat Method Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.4.1 Flat Modifying Method Call . . . . . . . . . . . . . . . . . . . 767.4.2 Reading Method Call . . . . . . . . . . . . . . . . . . . . . . . 81

8 Nested Distributed Actions 85

8.1 Follow-up Modifying Method Call . . . . . . . . . . . . . . . . . . . . 888.1.1 Initialization Phase . . . . . . . . . . . . . . . . . . . . . . . . 888.1.2 Pre-concurrency Control Phase . . . . . . . . . . . . . . . . . 898.1.3 Call-distribution Phase . . . . . . . . . . . . . . . . . . . . . . 918.1.4 Call-execution Phase . . . . . . . . . . . . . . . . . . . . . . . 928.1.5 Result-distribution Phase . . . . . . . . . . . . . . . . . . . . 928.1.6 Post-concurrency Control Phase . . . . . . . . . . . . . . . . . 938.1.7 Post-execution Phase . . . . . . . . . . . . . . . . . . . . . . . 938.1.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.2 Follow-up Reading Method Call . . . . . . . . . . . . . . . . . . . . . 958.2.1 Initiating Modifying Distributed Action . . . . . . . . . . . . . 968.2.2 Initiating Reading Method Call . . . . . . . . . . . . . . . . . 98

8.3 Follow-up Object Registration . . . . . . . . . . . . . . . . . . . . . . 998.3.1 Initialization Phase . . . . . . . . . . . . . . . . . . . . . . . . 1018.3.2 Call-distribution Phase . . . . . . . . . . . . . . . . . . . . . . 1028.3.3 Call-execution Phase . . . . . . . . . . . . . . . . . . . . . . . 1028.3.4 Concurrency Control Phase . . . . . . . . . . . . . . . . . . . 1038.3.5 Post-execution Phase . . . . . . . . . . . . . . . . . . . . . . . 103

8.4 Follow-up Object Duplication . . . . . . . . . . . . . . . . . . . . . . 1048.4.1 Initialization Phase . . . . . . . . . . . . . . . . . . . . . . . . 1058.4.2 Pre-concurrency Control Phase . . . . . . . . . . . . . . . . . 106

CONTENTS ix

8.4.3 Call-distribution Phase . . . . . . . . . . . . . . . . . . . . . . 1068.4.4 Call-execution Phase . . . . . . . . . . . . . . . . . . . . . . . 1068.4.5 Post-concurrency Control Phase . . . . . . . . . . . . . . . . . 1068.4.6 Post-execution Phase . . . . . . . . . . . . . . . . . . . . . . . 1068.4.7 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.5 Follow-up Object Deregistration . . . . . . . . . . . . . . . . . . . . . 108

9 Data Persistency 111

9.1 Shared Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129.1.1 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129.1.2 Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

9.2 Session State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169.2.1 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169.2.2 Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179.2.3 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

10 Latecomer Support 121

10.1 Direct State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 12210.1.1 Connection Phase . . . . . . . . . . . . . . . . . . . . . . . . . 12510.1.2 Initial Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12510.1.3 Final Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

10.2 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13310.2.1 Connection Phase . . . . . . . . . . . . . . . . . . . . . . . . . 13410.2.2 Initial Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13510.2.3 Final Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

11 Data Distribution 139

11.1 Static Distribution Schemes . . . . . . . . . . . . . . . . . . . . . . . 13911.2 Adaptive Distribution Schemes . . . . . . . . . . . . . . . . . . . . . 140

11.2.1 User-oriented Adaptive Distribution . . . . . . . . . . . . . . . 14311.2.2 Network-Oriented Adaptive Distribution . . . . . . . . . . . . 14511.2.3 State Transmission Protocol . . . . . . . . . . . . . . . . . . . 147

12 System Implementation 151

12.1 Communication Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 15312.2 Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15512.3 Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15712.4 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

13 Application Development and Reuse 165

13.1 Diagram Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16713.1.1 Step One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16813.1.2 Step Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16913.1.3 Step Three . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

13.2 Sketch Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17313.3 File Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

x CONTENTS

13.4 Spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17513.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

14 Conclusions 179

14.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17914.2 Comparison to Related Work . . . . . . . . . . . . . . . . . . . . . . 18214.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Bibliography 185

Index 199

List of Figures

2.1 Programmer-centered clover [Rot00b] . . . . . . . . . . . . . . . . . 8

2.2 Typical working environment of DreamTeam . . . . . . . . . . . . . 9

2.3 Runtime architecture of DreamTeam [Rot00b] . . . . . . . . . . . . 11

2.4 Collaborative virtual environment . . . . . . . . . . . . . . . . . . . 13

2.5 Partial class hierarchy of the CVE . . . . . . . . . . . . . . . . . . . 14

2.6 Central state distribution scheme . . . . . . . . . . . . . . . . . . . 16

2.7 Asymmetric state distribution scheme . . . . . . . . . . . . . . . . . 16

2.8 Replicated state distribution scheme . . . . . . . . . . . . . . . . . . 17

2.9 Partially-replicated state distribution scheme . . . . . . . . . . . . . 17

2.10 Consistency problem . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Architecture of Rendezvous [HBR+94] . . . . . . . . . . . . . . . . . 28

3.2 Architecture of Suite [DC92] . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Runtime architecture and process model of GroupKit [GR99] . . . . 31

3.4 Architecture of a COAST application process [SKSH96] . . . . . . . 32

3.5 Peer object-group design pattern in DAgora [SDMP97] . . . . . . . 33

3.6 System architecture of DyCE [TS00] . . . . . . . . . . . . . . . . . . 34

3.7 Runtime architecture of DistView [PS94] . . . . . . . . . . . . . . . 36

3.8 A Dragonfly component [AGW00] . . . . . . . . . . . . . . . . . . . 37

3.9 The use of wrappers in GEN [O’G96] . . . . . . . . . . . . . . . . . 40

4.1 Class hierarchy for a shared data object . . . . . . . . . . . . . . . . 44

5.1 Principle of the notification service . . . . . . . . . . . . . . . . . . . 48

5.2 The configuration dialog for the log window of the CVE . . . . . . . 52

6.1 Example lock allocation graph . . . . . . . . . . . . . . . . . . . . . 55

6.2 Class hierarchy of the locks . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Class hierarchy of the concurrency control schemes . . . . . . . . . . 60

7.1 Class hierarchy for the representation of a shared data object . . . . 66

7.2 Runtime failure during an object registration . . . . . . . . . . . . . 68

7.3 Example for an object registration . . . . . . . . . . . . . . . . . . . 69

7.4 Example for an object duplication . . . . . . . . . . . . . . . . . . . 73

7.5 Example for a modifying method call . . . . . . . . . . . . . . . . . 81

7.6 Example for a reading method call with a site crash . . . . . . . . . 83

xi

xii LIST OF FIGURES

8.1 Example for nested method calls . . . . . . . . . . . . . . . . . . . . 868.2 Execution order problem with nested modifying method calls . . . . 918.3 Example for nested modifying method calls . . . . . . . . . . . . . . 948.4 Example for a follow-up reading method call . . . . . . . . . . . . . 978.5 Example for nested reading method calls . . . . . . . . . . . . . . . 1008.6 Example for a follow-up object registration . . . . . . . . . . . . . . 1048.7 Example for nested object duplications . . . . . . . . . . . . . . . . 107

9.1 Inner object request . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139.2 Example for a load call . . . . . . . . . . . . . . . . . . . . . . . . . 1169.3 Session state storage dialog . . . . . . . . . . . . . . . . . . . . . . . 1179.4 Session state info dialog . . . . . . . . . . . . . . . . . . . . . . . . . 1189.5 Session state send dialog . . . . . . . . . . . . . . . . . . . . . . . . 119

10.1 A latecomer’s site receives a consistent state . . . . . . . . . . . . . 12310.2 A latecomer’s site does not receive a modifying message . . . . . . . 12310.3 A latecomer’s site receives a modifying message twice . . . . . . . . 12410.4 A user joins an active session . . . . . . . . . . . . . . . . . . . . . . 12510.5 Final phase problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 13210.6 Configuration dialog for a join with a replay . . . . . . . . . . . . . 135

11.1 Class hierarchy of static evaluators . . . . . . . . . . . . . . . . . . . 14011.2 Class hierarchy of adaptive evaluators . . . . . . . . . . . . . . . . . 141

12.1 Runtime integration of the object manager in DreamTeam . . . . . 15112.2 Layered runtime architecture of DreamObjects . . . . . . . . . . . . 15212.3 Class hierarchy for the integration of the object manager . . . . . . 15312.4 Partial class hierarchy of the communication layer . . . . . . . . . . 15412.5 Partial class hierarchy of the data layer . . . . . . . . . . . . . . . . 15612.6 Partial class hierarchy of the service layer . . . . . . . . . . . . . . . 15912.7 Class hierarchy of a collaborative application . . . . . . . . . . . . . 16212.8 Startup of a collaborative application . . . . . . . . . . . . . . . . . 163

13.1 A collaborative diagram editor . . . . . . . . . . . . . . . . . . . . . 16713.2 Class hierarchy of the single-user diagram editor . . . . . . . . . . . 16813.3 Class hierarchy of the multi-user diagram editor . . . . . . . . . . . 16813.4 Example for a bindSharedData method . . . . . . . . . . . . . . . . 16913.5 Data class hierarchy of the diagram editor . . . . . . . . . . . . . . 16913.6 Class header of the DiagramElement class . . . . . . . . . . . . . . . 17013.7 Example for a setObjectsState method . . . . . . . . . . . . . . . 17013.8 Example for a concurrency control configuration . . . . . . . . . . . 17113.9 Example for an inter-object concurrency control method . . . . . . . 17213.10 Example for a call-listener registration . . . . . . . . . . . . . . . . . 17213.11 Example for a shared data object registration . . . . . . . . . . . . . 17313.12 A collaborative sketch editor . . . . . . . . . . . . . . . . . . . . . . 17413.13 A collaborative file viewer . . . . . . . . . . . . . . . . . . . . . . . 17513.14 A collaborative spreadsheet tool . . . . . . . . . . . . . . . . . . . . 176

List of Tables

1.1 Time-space-taxonomy for groupware [EGR91] . . . . . . . . . . . . 1

2.1 Summary of requirements . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Method call event . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1 Constructor call message . . . . . . . . . . . . . . . . . . . . . . . . 677.2 Execution confirmation message . . . . . . . . . . . . . . . . . . . . 687.3 Registration permission message . . . . . . . . . . . . . . . . . . . . 687.4 Duplication call message . . . . . . . . . . . . . . . . . . . . . . . . 717.5 Deregistration call message . . . . . . . . . . . . . . . . . . . . . . . 747.6 Method call message . . . . . . . . . . . . . . . . . . . . . . . . . . 767.7 Call-listener add message for a particular data object . . . . . . . . 777.8 Call-listener add message for a type of data objects . . . . . . . . . 787.9 Method call result message . . . . . . . . . . . . . . . . . . . . . . . 797.10 Method call result sent confirmation message . . . . . . . . . . . . . 80

8.1 Possible nested distributed actions . . . . . . . . . . . . . . . . . . . 878.2 Follow-up method call message . . . . . . . . . . . . . . . . . . . . . 898.3 Method call start permit message . . . . . . . . . . . . . . . . . . . 908.4 Method call sent confirmation message . . . . . . . . . . . . . . . . 928.5 Follow-up method call result message . . . . . . . . . . . . . . . . . 928.6 Follow-up method call result sent confirmation message . . . . . . . 938.7 Follow-up constructor call message . . . . . . . . . . . . . . . . . . . 1018.8 Constructor call sent confirmation message . . . . . . . . . . . . . . 1028.9 Follow-up duplication call message . . . . . . . . . . . . . . . . . . . 1058.10 Follow-up deregistration call message . . . . . . . . . . . . . . . . . 109

9.1 Load call message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

10.1 Initial representation support message . . . . . . . . . . . . . . . . . 12610.2 Initial object support message . . . . . . . . . . . . . . . . . . . . . 12710.3 Initial support resume message . . . . . . . . . . . . . . . . . . . . . 12810.4 Final state request message . . . . . . . . . . . . . . . . . . . . . . . 12910.5 Final state support message . . . . . . . . . . . . . . . . . . . . . . 13010.6 Initial history support message . . . . . . . . . . . . . . . . . . . . . 13610.7 Initial history support request message . . . . . . . . . . . . . . . . 136

xiii

xiv LIST OF TABLES

10.8 Final history request message . . . . . . . . . . . . . . . . . . . . . 137

11.1 Data holder remove message . . . . . . . . . . . . . . . . . . . . . . 14411.2 Object state request message . . . . . . . . . . . . . . . . . . . . . . 14811.3 Object state transmit message . . . . . . . . . . . . . . . . . . . . . 14811.4 Data holder add message . . . . . . . . . . . . . . . . . . . . . . . . 149

13.1 Actions to transform the single-user diagram editor . . . . . . . . . 17713.2 Actions to transform the single-user sketch editor . . . . . . . . . . 17713.3 Actions to transform the single-user file viewer . . . . . . . . . . . . 17713.4 Actions to transform the single-user spreadsheet tool . . . . . . . . . 177

Nomenclature

Ad.c The tuple of constructor call arguments used for a constructor call d.c.

Ad.m The tuple of method call arguments used for a method call d.m.

app An application.

byted The byte representation of the shared data object d ∈ D.

CLm The set of call-listener for the method m.

CLsm The set of call-listeners for a method m ∈ MMd at a site s ∈ S.

c0 The default constructor of a shared data object.

Cd The set of constructors of a data object d ∈ D.

classd The class of a data object d ∈ D.

clone A special method that a data object offers for its duplication.

D The shared data objects of all applications in a collaborative session.

d.c A constructor call with d ∈ D and c ∈ Cd.

d.m A method call with d ∈ D and m ∈ Md.

DHd The set of data holders for an object d.

Dapp The shared data objects of the application app.

Dper The set of persistent shared data objects in D.

EMj An exclusive method set EMj ⊆ Md.

fcd.m The follow-up counter for a method call d.m.

fd The floor for a shared data object d ∈ D.

H The complete history list that contains all state changing messages.

Hs The history list at a site s ∈ S.

xv

xvi NOMENCLATURE

Hd The subset of the complete history list that contains all messages thatwere directed to d ∈ D.

Hsd The subset of Hd that is known to s ∈ S.

IOEMd.m The inter-object exclusive method set for a method call d.m.

Id The set of shared data objects that d ∈ D contains.

Isd The subset of Id that a site s ∈ S can determine.

idm The unique identifier for the method m ∈ Md.

ids The unique identifier for the site s ∈ S.

ioccm An inter-object concurrency control method for a method m ∈ Md.

Ld The set of locks for a shared data object d ∈ D.

MBslc The message buffer at the latecomer’s site slc ∈ S.

MCSd.m The method call stack for a method call d.m.

MLd.m The lock set for a method call d.m.

MMd The set of methods that modify a data object d ∈ D.

Md The set of methods of a data object d ∈ D.

named The registration name of a shared data object d ∈ D.

namem The name of a method m ∈ Md.

nameclassdThe name of a class of a data object d ∈ D.

OEMd The object exclusive method set for the object d.

rd.m The method call result of the method call d.m.

refd The reference of a shared data object d ∈ D.

refapp The reference of an application.

repd The representation of a shared data object d ∈ D.

S The set of sites participating in a collaborative session.

SCLm The set of sites that registered a call-listener for the method m ∈ MMd.

sd The site that creates a new shared data object d ∈ D.

sd.clone The site that duplicates the object d ∈ D.

sd.deregister The site that deregisters the object d ∈ D.

NOMENCLATURE xvii

sd.load The site that loads the object d ∈ D.

sd.m The site that initiates a method call d.m.

sd.store The site that stores the object d ∈ D.

sized The size of the data object d ∈ D in bytes.

TSH The timestamps of the messages in H.

ts A timestamp.

ts.cv The value of the logical clock that is contained in a timestamp ts.

ts.id The site identifier of a site that send a message with a timestamp ts.

tsd.clone The timestamp of the duplication call message for d.clone.

tsd.c The timestamp of the constructor call message for d.c.

tsd.deregister The timestamp of the deregistration call message for d.deregister.

tsd.load The timestamp of the load call message for d.load.

tsd.m The timestamp of the method call message for d.m.

tss1→s2The value of the logical clock at a site s1 ∈ S when it connects to s2 ∈ S.

wmd The write master of a shared data object d ∈ D.

xviii NOMENCLATURE

Chapter 1

Introduction

Nowadays, a lot of work is accomplished in teams. Teamwork uses the synergyeffects of different people with different expertises. Teammates collaborate to solvea specific problem or fellow students may learn collaboratively to pass an exam.Groupware is a technology that facilitates teamwork. It supports communication,coordination, and cooperative work between different team members. A well-knowndefinition of groupware was stated by Ellis et al. [EGR91]:

Groupware are computer-based systems that support groups of peopleengaged in a common task (or goal) and that provide an interface to ashared environment.

Currently, there exists a huge set of applications, which allow a team to workcollaboratively on a common task. A classification scheme for these applicationsis the time space taxonomy shown in table 1.1, which splits groupware into fourcategories. Each category represents a different kind of interaction.

Same time Different times

Same place Face-to-face interaction Asynchronous interaction

Different places Synchronous distributedinteraction

Asynchronous distributedinteraction

Table 1.1: Time-space-taxonomy for groupware [EGR91]

Interaction that happens at the same place and at the same time is called face-to-face interaction. Examples for this kind of groupware applications are meetingroom technologies like shared brainstorming or group moderation tools.

If the interaction takes place at the same place, but at different times, it is calledasynchronous interaction. Applications that support shift work or job sharing areput into this category.

Asynchronous distributed interaction takes place at different places and at dif-ferent times. Well-known examples are e-mail, workflow management systems, orshared document management systems.

Finally, interaction that happens at the same time, but at different places isreferred to as synchronous distributed interaction. Groupware that supports this

1

2 CHAPTER 1. INTRODUCTION

kind of interaction is called synchronous groupware. Synchronous groupware bringstogether users, who are geographically distributed and connected via a network. Itencompasses a wide range of applications like collaborative whiteboards, text editors,Web browsers or virtual environments. These applications facilitate communicationamong team members, when it otherwise is not possible. Companies may use it toreduce travel costs or to bring together expertise that is scattered between differentbranch offices.

Lauwers and Lantz [LL90] distinguish two kinds of synchronous groupware ap-plications:

• Collaboration-transparent applications are original single-user applicationswhich run in a collaborative environment (e.g. a shared windows system).

• Collaboration-aware applications are designed especially for collaboratingteams. Such an application usually has to be developed ’from-scratch’, butoffers a huge variety of group-specific services to end-users.

Collaboration-transparent applications achieve collaboration by capturing userevents and distributing them to the other participants. An obvious advantage ofthis approach is that an existing single-user application can be reused for collabo-ration. A user can work in a familiar environment and a developer need not writeany new code to make an application collaborative. An obvious drawback is thatsingle-user applications by definition do not offer any group-specific services, andcan hardly produce any group feeling (so-called collaboration-awareness). However,collaboration-awareness is an important requirement for collaborative applications.Without support for collaboration-awareness, it is difficult to facilitate coordinationand to establish a social space, as other group members are not physically presentat the same place.

In contrast to collaboration-transparent applications, collaboration-aware ap-plications offer group-specific services that can be used to achieve collaboration-awareness. However, developing such an application is a difficult and time-consuming task. Apart from the actual task of the application, e.g. editing texts orspreadsheets,

• network connections between the collaborating users have to be established,

• parallel input from many users has to be handled,

• specific group functions have to be included, and

• shared data have to be managed.

The development of a collaboration-aware applications can be simplified by pro-viding a platform that offers solutions for these recurring tasks as building blocks.Based on these building blocks, a developer can implement a collaboration-awareapplication that is especially tailored to the demands of a collaborating group.

The wide range of synchronous groupware applications leads to different require-ments on a platform. A platform has to provide a variety of building blocks from

1.1. PROBLEM STATEMENT AND APPROACH 3

which a developer can select the appropriate ones. The offered solutions have to beflexible, i.e. a developer must be able to adapt them to application-specific needs.As there may be special requirements that a platform does not meet, it has to beextensible. Developers must be able to integrate their own solutions in the platform.

There already exist platforms that support the development of collaboration-aware applications. Most of them do not especially focus on shared data managementand therefore provide only rudimentary support for data sharing. At our institute,Roth developed the DreamTeam platform [Rot00a, Rot00b]. DreamTeam is imple-mented in the object-oriented programming language Java [SUN02]. It concentrateson the communication and coordination of distributed users.

We created several groupware applications with DreamTeam, e.g. a brainstorm-ing tool, a collaborative Web browser, and a distance teaching environment [LRU99,LR00]. During the development, we noticed that the main obstacles are concernedwith data sharing issues, e.g. to distribute the data, to keep the shared data consis-tent, or to permanently store the shared data.

1.1 Problem Statement and Approach

The primary goal of this thesis is to simplify the development of groupware applica-tions by providing a platform that relieves developers from all data sharing issues.The development of a groupware application should be almost as simple as the de-velopment of a single-user application. A platform should support a developer insuch a way that he can concentrate on application-specific details. For this purpose,a platform has to handle all data sharing issues transparently. Additionally, thisplatform has to be extensible and adaptable to the specific needs of a groupwareapplication.

This thesis describes the DreamObjects platform that substantially simplifiesthe development of shared data objects. As the DreamTeam platform was devel-oped at our institute, DreamObjects takes DreamTeam as a starting point and en-hances it with services for shared data management. For integration in DreamTeam,DreamObjects is implemented in Java, too. DreamTeam and DreamObjects com-plement each other and together substantially simplify the development of all formsof synchronous groupware.

DreamObjects consists of two parts, an object-oriented framework and a run-time environment. The object-oriented framework of DreamObjects offers buildingblocks for the development of shared data objects. These building blocks offer alot of configuration possibilities. A developer can feel free to compose data objectsor reuse existing data classes from single-user applications. The runtime environ-ment of DreamObjects offers a set of services for data sharing. By applying theobject-oriented substitution principle, DreamObjects hides most of these servicesand achieves a maximum of transparency, i.e. a developer does not have to careabout how the services actually work. After an initial configuration, a developercan use a shared data object like a local data object. Apart from these benefits, themain contributions of DreamObjects are:


• Flexible and extensible data distribution: There have been a lot of discussionsabout the best distribution scheme for the data objects of a groupware ap-plication. Many existing groupware platforms only support one distributionscheme, e.g. a replicated or a central one. The supported distribution schemeapplies to all applications that are developed with this platform. However, dif-ferent applications or even a single application can have different requirementsconcerning data distribution. In DreamObjects, developers can choose be-tween an asymmetric, a replicated, and different adaptive distribution schemes.Adaptive distribution schemes dynamically change the distribution of a shareddata object according to a user’s working style or according to the topologyof the connecting network. Additionally, DreamObjects offers interfaces andbuilding blocks that permit developers to define their own distribution schemesand integrate them into the platform.

• Flexible and extensible concurrency control : As the discussions about the bestconcurrency control mechanisms for synchronous groupware are not finishedyet, DreamObjects offers a developer different concurrency control schemesand permits a developer to tailor the concurrency control to application-specific needs.

• Adaptable notification service: Using the notification service, a developer canseparate user interface and data and track local as well as remote changes.To avoid unnecessary notifications, he can restrict them to application-specificneeds.

• Runtime configuration: A developer can specify the distribution scheme of ashared data object and its concurrency control at runtime. Thereby, he can usethe same data object with different configurations and adapt the configurationto the runtime needs of an application.

• Flexible latecomer support : A user who joins a session, i.e. a latecomer, canchoose, if he wants to join with a replay of the session or with a direct statetransfer. Both mechanisms are fault-tolerant, e.g. the site that supports alatecomer can leave the session. They do not block the current participantsin their work. Additionally, they work decentralized and are integrated in theruntime environment. Thereby, DreamObjects completely relieves a developerfrom the task to support the latecomer with a consistent state.

• Decentralized persistency service: It can be difficult for some groups to find apoint of time at which all members can participate in a session, for other groupsto cooperate for a long time. DreamObjects offers a decentralized persistencyservice to support the transition between asynchronous and synchronous work.A developer can use this service to store and load shared data objects. A usercan employ this service to store, load, and distribute session states.

1.2. ORGANIZATION OF THE THESIS 5

1.2 Organization of the Thesis

The remainder of this thesis has the following structure:Chapter 2 specifies the requirements on an ideal platform that simplifies the

development of shared data for synchronous groupware. It first introduces a modelthat describes the needs of groupware developers. Based on this model the chapterworks out the requirements and splits them up in issues concerning data distribution,data consistency, concurrency control, and data persistency.

Chapter 3 classifies existing groupware platforms according to the way how theydistribute the state of a collaborative application. It describes some platforms foreach identified class and discusses their benefits and drawbacks.

Chapter 4 to 11 describes the solutions following the requirements as stated inchapter 2. Chapter 5 describes the notification service that enables a developer totrack local as well as remote changes to the shared state.

Chapter 6 describes the supported concurrency control mechanisms. Further-more, the chapter presents how a developer can tailor the concurrency control toapplication-specific needs.

Chapter 7 classifies possible state modifications, before it presents the substitu-tion principle that DreamObjects uses to achieve transparency. It introduces theservices that DreamObjects uses to keep the shared state consistent, e.g. how itcreates shared data objects or how it handles modifying method calls.

DreamObjects supports composite shared objects. In such objects, it is usual tonest method calls or object creations. Chapter 8 describes the problems that arise,when such actions are nested. Then it presents how DreamObjects solves theseproblems, while preserving a maximum of transparency.

Chapter 9 presents the data persistency service that is necessary to support atransition between synchronous and asynchronous work.

Chapter 10 first introduces the problems that a decentralized latecomer supporthas to solve. Then it explains the different mechanisms that DreamObjects offersto accommodate latecomers.

Chapter 11 describes the different supported distribution schemes. It explainshow developers can configure the supported distribution schemes and how he canuse the offered building blocks to define their own distribution schemes.

Chapter 12 presents the layered runtime architecture of DreamObjects. It de-scribes each layer and how a developer can implement a collaborative applicationthat accesses the services of DreamObjects.

Chapter 13 presents a three-step approach for the transformation of single-user applications into collaborative ones. The three-step approach illustrates howDreamTeam and DreamObjects work together and substantially simplify the devel-opment of synchronous groupware.

Finally, chapter 14 summarizes the thesis and discusses possible future areas ofresearch.

Chapter 2

System Requirements

The functions of a groupware application can be divided into domains. The clovermodel [CCN97], e.g., distinguishes three domains: production, coordination andcommunication. It provides a user-centered view of groupware. It can be used todetermine the requirements of a user without considering the software developmentprocess.

Roth [Rot00b] pursues a different direction and introduces a programmer-centeredclover model to describe the needs of groupware developers. This model divides thefunctions of a groupware application into the following domains:

• Coordination: To collaborate, users must be able to coordinate their work, e.g.plan and schedule future sessions.

• Communication: A groupware application has to communicate with applica-tion components at other computers. This includes establishing communica-tion links, transferring data and supervising connections.

• Data: Single-user applications as well as groupware applications have to man-age their data, but groupware applications have to share their data to allowusers to collaborate. Data management is the main difference between devel-oping single-user applications and groupware applications.

• User interface: Compared to a single-user applications, a groupware applica-tion has to manage input from many users simultaneously. In reaction to this,output from synchronous data manipulations has to be presented via the userinterface.

Fig. 2.1 a) shows these domains. Communication and coordination are fullygroupware-specific, whereas the domains data and user interface are relevant forgroupware functions as well as for single-user functions. This leads to two basicfunction types, an application has to provide (see fig. 2.1 b)):

• Application functions define the fundamental behavior of an application, e.g.in the case of a collaborative text editor, application functions define how toedit, cut and paste, mark and print text.

7

8 CHAPTER 2. SYSTEM REQUIREMENTS

C Coordination

Communica-

tion Data

User

Interface

a)

C D

UI

b)

Consis

tency

Data

dis

tributio

n

Concurre

ncy c

ontro

l

Consistency

Collaboration A

wareness

Consiste

ncy

Persiste

ncy

Single-user

functions

Establishing

and managing of

communication

links

Data transport RPC

Group

functions

Applicatio

n

functions

Group rendezvous

Session management

Announcement service

User managerment

Configuration

Figure 2.1: Programmer-centered clover [Rot00b]

• Group functions define the behavior of an application for a group. They, e.g.,define how to change text simultaneously and how to display telepointers.

A platform for synchronous groupware ideally supports a developer in all do-mains of the programmer-centered clover model. The following section describesthe DreamTeam platform [Rot00b] that is taken as starting point in this thesis.DreamTeam completely covers the domains communication and coordination. Itpartly supports a developer in the user interface domain, as providing a user inter-face is mainly a task of the application itself rather than the platform.

2.1 DreamTeam

DreamTeam is a platform for synchronous collaboration-aware applications and of-fers a variety of services for application developers as well as for end-users. It allowsa developer to develop cooperative applications almost like single-user applications.DreamTeam is based on a fully decentralized architecture, i.e. no well-known serveris needed. The decentralized architecture leads to more complex algorithms, never-theless it avoids performance bottlenecks and makes the system much more reliable.DreamTeam is entirely developed in Java [SUN02], and thus can be run on many op-erating systems. Its architecture consists of a development environment, a runtimeenvironment, and a simulation environment.

The development environment offers a big hierarchical class library with group-ware specific solutions. These solutions include a set of group-specific user interfacecomponents such as participant windows, distributed mouse pointers and overviewwindows. These components can be integrated into existing user interfaces without

2.1. DREAMTEAM 9

too much integration cost.DreamTeam provides a multicast remote procedure call (RPC) that can be com-

pared with the one-to-many remote procedure call discussed in [Coo85]. A developercan use the multicast RPC to realize replicated data objects by, e.g., distributinglocal modifications of a data object to the respective remote instances. DreamTeamoffers pessimistic locks to avoid that several users can modify the same data objectat the same time. These locks can be applied on a per-object basis and allow onlyone user to change a data object at a time. Transactions are not directly supported.

DreamTeam uses the session metaphor [GR98]. The session metaphor restrictsthe collaboration of a team to so-called sessions. Normally, one group member startsa session and after this the other participants can join the session. When their workis done, the participants leave the session. Groupware that is based on the sessionmetaphor concentrates on synchronous collaboration. A metaphor that supportsasynchronous work is called the room metaphor [GR98]. The members of a groupcan enter so-called rooms to start collaboration. A room can contain collaborativeapplications or shared documents. To support asynchronous work the data of thecollaborative applications or the shared documents are persistently stored on a well-known server. A drawback of this approach is that it is neither possible to resumecollaborative work nor to start collaboration, when this server is not available.

The runtime environment of DreamTeam provides an infrastructure with specialgroupware facilities, which allow a user to start collaborative applications. An ap-plication that is started in a session is by default started in a public mode, but a usercan also start an application in a so-called private mode. If an application is startedin the private mode, it behaves like a single-user application. In the private mode auser can get familiar with the application that is later used in a shared environment.

Figure 2.2: Typical working environment of DreamTeam

With the front-end included in the runtime environment a user can interact withthe system. Fig. 2.2 shows a typical working environment. The upper left corner ofthe screenshot shows the main window of DreamTeam from which a user can open


all other windows of the front-end, e.g. the online-list, the public sessions window,or the configuration window. The upper right window contains the public sessionswhich a user can start, join, or leave. The lower right window displays the online-listwhich contains all users currently online.

In addition to the front-end, the runtime environment starts and controls a list ofmanagers that fulfill groupware-related tasks. The session manager is responsiblefor starting, joining, and leaving sessions. When a team starts organizing a session,several decisions have to be made: regarding the date and duration of the session,the applications to be used, participation restrictions etc. DreamTeam stores this setof information in a so-called session profile. There can be several applications in asession profile. Local session profiles and profiles of remote sessions are stored by thelocal system. The list of all available session profiles is called the session list, whichgives the user an overview about planned and ongoing sessions. The session profilesand the session list form the basis for all coordination functions that DreamTeamoffers. The user who creates a session profile is called the session originator. Onlythe session originator can modify the session profile or start and stop the session.

Like Schooler [Sch96], DreamTeam distinguishes between long-term rendezvousand short-term rendezvous. The long-term rendezvous supports long-term planningand session announcements. The short-term rendezvous supports a user at themoment when a session actually starts. The user’s system must get informationabout the current list of users who want to attend the session and the list of theircorresponding network addresses. The rendezvous manager [RU99] offers a solutionfor the short-term and the long-term rendezvous. For the long-term rendezvous, themanager uses two mechanisms. One mechanism directly exchanges session profileswhen two or more members are online at the same time. A second mechanism usesthe standard e-mail and newsgroup services for distributing session profiles. Analgorithm, which reduces network traffic, handles the short-time rendezvous. Justbefore the session starts, this algorithm determines the actual network addresses ofall team members.

After starting a session, the connection manager is activated. The connectionmanager uses the information that was gathered by the rendezvous manager toestablish bidirectional communication links between all participants of a runningsession. An application developer can access the communication functions via awell-defined interface.

DreamTeam supports meeting rooms. Meeting rooms are different to single-userworking places as they offer a variety of special equipment, e.g. cameras, projectors,or tablets. This equipment can be connected to different computers. The nodemanager of DreamTeam treats all computers in a meeting room as a single one andmanages the communication between them.

The archive manager can be viewed as a small database for long-term data suchas old user profiles or profiles of terminated sessions. It stores the user profile ofevery user with whom the local user has ever collaborated. The front-end allows toview and manage these user profiles.

The transfer manager provides data transport for slow data. A participant of arunning session can transfer a file to another participant in the same session. For

2.1. DREAMTEAM 11

this purpose, the transfer manager uses a separate connection to this participantwhich does not effect the normal session communication.

The third part of the DreamTeam platform, the simulation environment, is usedto simulate networks with limited bandwidths and high network delays. Every com-munication channel can be configured separately. To detect performance problems,the simulation environment provides report functions for network loads. Testingshared applications inside the simulation environment ensures stability for real us-age and avoids performance problems which otherwise would be detected very latein the development cycle.

Runtime environment and control

Network, operating system, Java VM

Network

Kernel

Manager layer

Fra

mew

ork

exte

nsio

ns

Ap

plicati

on

serv

ice layer

(AS

L)

Fra

mew

ork

develo

pm

en

t inte

rface (F

DI)

Gro

up

ware

ap

plicati

on

s Front-End

Rendezvous

manager

Node manager

Connection

manager

Archive manager

Session manager

Transfer

manager

Kernel layer

Persistency

kernel

System

protocol Network kernel interface

Network

kernel

Figure 2.3: Runtime architecture of DreamTeam [Rot00b]

Fig. 2.3 shows the runtime architecture of DreamTeam. The arrows indicate aservice usage and not a data flow. It is divided in the following parts:

1. The operating system and the included network services as well as the Javavirtual machine.

2. The runtime environment consists of the kernel layer, the manager layer, andthe front-end. As already discussed, the managers fulfill special tasks. Ker-nels offer low level services. The persistency kernel stores the configurationdata of the runtime system. The system protocol persistently logs relevantmessages of the runtime system. The network kernel interface (NKI) [Rot99]encapsulates all network related services. It can be used for establishing net-work connections or multicasting messages. By default, all kernel services aremapped to TCP/IP [Pos81b, Pos81a]. The kernel can be exchanged to, e.g.,use a network that supports IP multicasting [Dee89]. This allows a developer


to use different networks without changing the collaborative applications orthe DreamTeam platform.

3. Groupware applications are connected with the runtime environment via theapplication service layer (ASL).

4. Possible framework extensions can be integrated into the framework via theframework developer interface (FDI). FDI allows a developer to add managersto the manager layer without modifying the rest of the platform.

2.2 Requirements in the Data Domain

DreamTeam entirely covers the domains coordination and communication of theprogrammer-centered clover model, i.e. an application developer need not implementany functions of these domains himself. The coordination domain is covered by therendezvous, the session, and the archive manager and the communication domain iscovered by the connection manager, the NKI, and the multicast RPC. In the userinterface domain, DreamTeam offers user interface components that can be usedto provide collaboration awareness. In the data domain, DreamTeam just offers arudimentary support. Thus, developers completely have to be aware of data sharingissues.

To simplify the development of groupware applications, a platform has to relievea developer from data sharing issues. The data domain of the programmer-centeredclover model is split up in the sub-domains data distribution, data consistency, con-currency control, and data persistency (see fig. 2.1). Therefore, DreamTeam has tobe extended and the extension has to fulfill the following requirement:

R1: Developers must be provided with services concerning data distribution, dataconsistency, concurrency control, and data persistency.

As in our opinion the development of a groupware application should be almostas easy as the development of a single-user application, a developer should not haveto care about how the services actually work. Developers should be able to use ashared data object almost like a local data object of a single-user application. Ifthis is achieved, a developer can concentrate on application-specific details insteadof struggling with data sharing issues. Thus, the following requirement must be met:

R2: Developers must be able to use shared data objects transparently.

Before the following sections discuss and determine the further requirementsconcerning data distribution, data consistency, concurrency control, and data per-sistency, the next section introduces an example application that is used throughoutthis thesis to reveal requirements and to illustrate concepts.

2.2. REQUIREMENTS IN THE DATA DOMAIN 13

2.2.1 Example Application

Fig. 2.4 shows a screenshot of a collaborative virtual environment (CVE). CVEsare a combination of virtual reality and groupware. They become more and morepopular. Benford et al. [BGRP01] state that the shared data management in CVEsrepresents a major challenge. The CVE in fig. 2.4 was developed with the solutionthat is presented in this thesis and DreamTeam.

Figure 2.4: Collaborative virtual environment

The depicted CVE allows users to walk through virtual rooms and to furnishthem collaboratively. The upper left window shows the top-view of the environment.Circles represent users, the thick black lines represent walls, and the differently col-ored rectangles represent furniture. Currently, you can see two users, some tables,and some wardrobes. A user can select a piece of furniture and delete it. Fur-thermore, a user can select a part of the room and create a new piece of furniture.The lower left window shows the log window of the CVE. The log window displaysthe actions of the users that currently work in the CVE. A user can configure thelog window to only display the information he is interested in. The right windowcontains the 3D-view of the environment. You can see the avatar of another user,a table with a lamp on its top, a wardrobe, and some ceiling lights. The contextmenu indicates that the local user picked the displayed table. It allows the localuser to move the table, put something on the table, change the appearance of thetable, resize it, or even delete it.


Fig. 2.5 shows a part of the class hierarchy of the CVE. The CVE class representsthe application. At runtime, an instance of the Environment class describes thevirtual environment. For every room in the virtual environment, it contains aninstance of the Room class. Each piece of furniture is represented by an instance ofa corresponding data class. Each class for a piece of furniture extends the Element

class. This class defines methods that are common for every piece of furniture.An instance of the Room class contains instances for every piece of furniture thatis associated with the respective room. An instance of the Table class containsthe elements that were put on it, e.g. a table lamp. Additionally, it contains acollision matrix. The collision matrix is a discrete representation of the table top.Each element on top of a table allocates a part of the matrix. Thereby, the collisionmatrix can be used to coordinate the movement of the elements on top of a table. Forthe same reasons, the application uses a collision matrix to coordinate the movementof the users and the furniture. The instances of all these data classes have to beshared, as otherwise a collaboration among the users is impossible.

Environment Room

User

Users

CollisionMatrix

CVE

TableLamp

TableCollisionMatrix

Wardrobe Lamp Table Chair

Element

Whiteboard

Figure 2.5: Partial class hierarchy of the CVE

This partial class hierarchy reveals that the extension of DreamTeam has tosupport composite shared data objects. Additionally, a developer must be able toreuse or generalize existing data classes by inheritance. Summing up, the followingrequirement must be fulfilled:

R3: Developers must not be restricted during the implementation of shared dataobjects.

2.2.2 Data Distribution

Roth et al. [RU00] introduce an extensible classification model for synchronousgroupware. In contrast to former classification models, e.g. Patterson’s taxonomy[Pat95] or Dewan’s generic architecture [Dew96], this model directly addresses thedistribution characteristics of a groupware application. With its help existing group-ware platforms can be classified. It consists of an application scheme and a distri-bution scheme.


An application scheme describes how an application can be divided into com-ponents and how these components interact. It tries to answer how to build agroupware system that allows users to interact with each other via shared data.Roth’s application scheme was influenced by Arch [UIM92], an application schemefor single-user applications. There are a lot of further application schemes like ALV[Hil92, HBR+94], PAC∗ [CCN97] or multi-user MVC derived from MVC [KP88].All application schemes strictly separate the user interface of an application fromthe underlying data and algorithms. The user interface objects control the user in-terface behavior of an application and display the content of the data objects. Userscollaborate by modifying the shared data objects via the user interface of the appli-cation. This separation has the advantage that it is possible to implement differentuser interfaces for the same underlying data. To take advantage of this separation,the following requirement must be fulfilled:

R4: A collaborative application has to be divided in data objects and user interfaceobjects.

As a result, the shared data objects can be manipulated unnoticed from a localapplication and an application must be able to react on remote changes. Thus, thefollowing requirement has to be met:

R5: A notification service must inform interested objects, whenever a shared dataobject changes.

Roth et al. use their application scheme to classify existing groupware platforms.For this purpose, they discuss different variations concerning the distribution ofshared data objects. They identify the following distribution schemes:

1. Central state

2. Asymmetric state

3. Replicated state

Fig. 2.6 shows the central state distribution scheme. The dotted frames indicatedifferent sites inside a network. The user interface is replicated to every site. Awell-known server manages the shared data objects of an application. Lewandowskiet al. [Lew98] and Plasil et al. [PS98] give an overview about some frameworks, e.g.CORBA, that offer services for this kind of architecture. The main advantage of thisdistribution scheme is that it is very simple to ensure data consistency and to handlepersistency. However, one has to maintain the server. The server is a bottleneck forthe communication between the participating sites and slow network connectionscan increase the time an application needs to access the shared data objects andpropagate possible effects to the user interface objects. This time is called responsetime. For interactive applications, it is a quite important issue to keep the responsetime low, as this time is directly perceived by the user and a high response timedisturbs the interaction of the user with the application.


Shared data

objects

User interface

objects

User interface

objects

Figure 2.6: Central state distribution scheme

In the asymmetric state distribution scheme (see fig. 2.7), an arbitrary partici-pating site fulfills the tasks of a server. Using this scheme, every participant caneasily share local data. Apart from this advantage, this scheme has the same draw-backs as the central distribution scheme. In the CVE, e.g., this distribution schemeis used for the data objects that represent the users, as these data objects are onlyneeded as long as the respective user participates in the session.

Shared data

objects

User interface

objects

User interface

objects

Figure 2.7: Asymmetric state distribution scheme

In the replicated state distribution scheme (see fig. 2.8), shared data objects aredistributed to every participating site. As an application can access the shared dataobjects locally, the response time of an application is reduced. However, as alreadydiscussed by Molina [GM86], this distribution scheme has its drawbacks as well. Theruntime system has to use more complex algorithms, e.g. for concurrency control.The network traffic for keeping shared data consistent increases, as every site hasto be informed about a modification. In the CVE, e.g., this distribution scheme isused for the collision matrix, as every site has to access the matrix, whenever thelocal user either moves himself or a piece of furniture.

A variant of the replicated distribution scheme is the partially-replicated one. Inthis distribution scheme shared data objects are distributed to more than one site,but not necessarily to all sites. Compared to the asymmetric and central distribution


Shared data

objects

User interface

objects

User interface

objects

Shared data

objects

Figure 2.8: Replicated state distribution scheme

scheme, this increases the availability of the shared data. Compared to the replicateddistribution scheme, this decreases the network traffic that is necessary to keep theshared state consistent. However, the runtime system still has to use more complexalgorithms.

There exist different approaches for a partially-replicated distribution scheme.Shared data objects can, e.g., be replicated to a predefined set of sites. These sitescan access the shared state locally and have to keep the shared state consistent.Other sites choose an arbitrary site to access the shared state. Fig. 2.9 shows thisscenario. On the one hand, this approach increases the availability of the shareddata objects, but on the other hand the predefined sites need not be the sites thatintensively access them.

Shared data

objects

User interface

objects

User interface

objects

Shared data

objects

User interface

objects

Figure 2.9: Partially-replicated state distribution scheme

Normally, not all users view or edit all shared data objects. Thus, not everyparticipating site requires all shared data objects at all times. Instead, a site onlyrequires those shared data objects the user currently views or edits. Other shareddata objects that also belong to the state of the collaborative application can beignored without any adverse effect to the user interface.

To take this into account, a platform could replicate a shared data object ondemand, e.g. as soon as a user accesses the part of a document that the shared


data object represents. When a site does not access a shared data object anymore,e.g. the local user changed his working focus, it has to discard it. Otherwise theset of replicas continually grows and finally the shared data object is replicated toall participating sites. However, as the working style of a user is not deterministic,this approach can lead to high communication costs. For instance, consider a userwho just takes a short look on a document part and then continues his work on adifferent document part. In the worst case, the runtime system would request theshared data object and almost immediately discard it.

A partially-replicated distribution scheme that takes the changing working styleinto account, is called adaptive or dynamic and was postulated by Gavish et al.[GS90]. Wolfson et al. [WJ92a, WJ92b, HW93, WJH97] introduce several dis-tributed algorithms for an adaptive replication. The algorithms use different cost-functions to adapt the replication scheme of a shared data object. The cost func-tions are based on the read-write pattern on the shared data object. Wolfson et al.[WJH97] compare their algorithm with different static replication schemes in a givennetwork topology. They show that their adaptive replication algorithm significantlyreduces network traffic.

From all partially-replicated distribution schemes, the adaptive one offers themost advantages. In the CVE, e.g., an adaptive distribution scheme is used for theshared data objects that represent a piece of furniture. As usually not all usersmodify and view all pieces of furniture at all times, this distribution scheme canadapt the replication to the current requirements.

The discussion shows that every of the presented distribution schemes has itsdrawbacks and advantages and that none suits well for every groupware applicationor even for single data objects of an application. This leads to the next requirement:

R6: Developers must be able to define the distribution scheme per shared object.

The asymmetric distribution scheme fits well, when a user wants to introducelocal data into a collaborative session. The replicated distribution scheme offershigh responsiveness. A developer might choose an adaptive distribution scheme, ifhe on the one hand wants to increase the availability of a data object and on theother hand, compared to the replicated distribution scheme, wants to decrease thenetwork traffic. He might also choose an adaptive distribution scheme, if the dataof an application can be divided into single logical pieces, e.g. a text document, andhe wants to adapt the distribution of the data to a user’s working style. From thisdiscussion, the following requirement can be derived:

R7: Developers must be able to choose between an asymmetric, a replicated, andan adaptive distribution scheme.

Even the above distribution schemes may not fulfill the requirements of all ap-plications. If the participants of a session are predefined and thus the connectingnetwork is known, a developer may want to define his own distribution scheme thatis especially adapted to this environment, e.g. he can replicate shared data objects tothe sites that serve as junctions in the connecting network topology. So the following


requirement must be fulfilled:

R8: Developers must be able to configure the predefined distribution schemes andto introduce their own distribution schemes.

2.2.3 Data Consistency

The state of a collaborative application changes during a session: a shared dataobject may be created, deleted, or modified. To keep the shared state consistent asite has to notify the other sites, whenever it changes the state of a collaborativeapplication.

An application developer is not interested in taking care of such changes. Hewants to use a shared data object like a local object without thinking about dataconsistency issues. A developer is used to call methods, if he wants to modify adata object or simply wants to read a value from the data object. Due to thedifferent distribution schemes, it is possible that a site does not hold a copy of ashared data object and thus cannot execute a method call locally. If a site executesa modifying method call, this changes the content of the shared data object. Tokeep the shared data object consistent, this method call must be executed at everysite that maintains a copy of the shared data object. Similarly, a developer is usedto create data objects by executing a constructor. If the content of the data objecthas to be shared, the participating sites must be informed about the creation of anew data object. This leads to the following requirement:

R9: A set of distributed actions must transparently handle shared state changes aswell as accesses.

Complex collaborative applications, like the CVE, often use composite data ob-jects. For a developer it is normal to nest method calls, i.e. to call a method of adata object from another method. In the CVE, the move method of the table callsthe move method of the lamps on top of the table, whenever a user moves a tablewith lamps on top of it. In a distributed setting, this may lead to unintended effects.Since the move method modifies the content of the table, every site that maintainsa copy of the table must be informed about the state change and apply it. Everysite that applies the state change of the table also executes the move method of thelamps. If the table and the lamps use a replicated distribution scheme, it is notnecessary to distribute the state change of the lamps, as every site already knows it.However, if different distribution schemes are used, it must be ensured that everysite that maintains a copy of a lamp is informed about the state change of the lampand applies this state change only once. For instance, consider that every site thatmaintains a copy of the table informs the sites that maintain a copy of the lamps.In this case, it must be prevented that the state change of the lamps is executed asoften as there are sites that maintain a copy of the table. Otherwise, this can leadto an unintended position of the lamps. As this example is not limited to modifying


method calls, the following requirement must be met:

R10: The effects of different distribution schemes concerning nested shared statechanges as well as accesses must be considered.

Users or sites can either join a session or leave it. If a shared data object, e.g.,uses an adaptive distribution scheme and all sites that keep a copy of a shared dataobject become unavailable, the shared data object cannot be accessed anymore.To permit ongoing collaboration, even when users or sites become unavailable, thefollowing requirement has to be fulfilled:

R11: A user or site that becomes unavailable must not affect the consistency andavailability of the shared state.

A user who joins a session is called latecomer. To participate in the session alatecomer needs the current shared state. Lauwers and Lantz [LL90] discuss somebasic mechanisms that allow a latecomer to join a session and provide the latecomerwith the current state. A latecomer can join a session with a replay of how thecurrent state was reached. The basic idea of this mechanism is to log all modifyingevents in a history list. When a latecomer joins the session, this history list isreplayed to bring the latecomer up-to-date. However, if, e.g., an event depends onexternal information, it may not be possible to replay the log correctly. In additionto this, histories can require a lot of memory space and replaying can be time-consuming. Compared to a replay, the direct state transfer provides a faster wayto bring the latecomer up-to-date, as the shared state is directly transferred from asupporting site to the latecomer’s site.

As long as the shared state is maintained on a well-known site, it is quite simpleto support the latecomer with the current state. As soon as the shared state isreplicated or even partially-replicated, this task becomes quite difficult. To simplifythe development of groupware applications, the following requirement has to besatisfied:

R12: A platform-provided latecomer support must relieve the developer.

Sometimes it can be easier for a latecomer to participate in the session, when heknows how the current session state was reached. However, some latecomers maynot be interested in a replay and instead want to join the session in a faster way.Therefore, it depends on the latecomer which mechanism is reasonable:

R13: Latecomers must be able to choose, if they want to join with a replay or witha direct state transfer.

2.2.4 Concurrency Control

As stated in the previous section, the extension of DreamTeam has to offer a dis-tributed action that notifies the participating sites, whenever the shared state is


modified. Fig. 2.10 shows that such a distributed action is not enough to ensurethe consistency of the shared data objects. Imagine that three users collaborativelywork in the CVE as depicted in fig. 2.4. User one and user three move the sametable and inform the respective other sites about the state change. Due to networktransmission times and network latency, the execution order is not the same at everysite. This can lead to inconsistencies.

t t t

move 1

move 2

move 1

move 1

move 2

move 2

User 1 User 2 User 3

Figure 2.10: Consistency problem

There exist a lot of approaches to ensure a correct execution order. These ap-proaches are called concurrency control. They are based on the idea to coordinateinterfering distributed actions. Some approaches involve the runtime system, whileothers involve the user. As it is not enough to distribute changes, the followingrequirement must be met:

R14: A concurrency control service must ensure a correct execution order.

Some platforms rely on a social protocol [GM94] to ensure the consistency ofshared data objects. The social protocol involves the user. Normally, when userswork together, they mediate their actions such that the actions do not interfere.When they, e.g., work on a real whiteboard, they would consider it as bad behaviorto overwrite another user’s notes. The same applies for a collaborative whiteboard.The collaborative application has to make the users aware of the other users’ actionsto support social protocols. Even when the users follow a social protocol, inconsis-tencies can arise due to, e.g., carelessness. Thus, a social protocol cannot guaranteea consistent state. However, for some applications, e.g. a sketch editor, this is ac-ceptable, as a sketch editor often is used to develop ideas and not to produce a finaldocument.

Another approach that involves the user is called floor control. Before a user canmodify the shared state, he has to own the floor. A well-known example for floor


control is turn-taking on the audio channel in a collaborative conference application.Only the user that owns the floor can speak. For this purpose, he has to requestthe floor explicitly. There exist a lot of further policies to pass the floor amongthe participants of a collaborative session. For instance, it could be the task of thesession chair to pass the floor among the participants or the right to own a floorcould be based upon time-outs [DGLA97]. Summing up, floor control can be usedin collaborative multimedia or conference applications, but not in sessions with highparallelism, since an obvious drawback of the floor control mechanism is the lack ofconcurrency.

Greenberg and Marwood [GM94] compare and classify approaches that are han-dled by the runtime system. They define two classes:

1. Concurrency control through serialization

2. Concurrency control through locking

Concurrency control through serialization is based on a total ordering of alldistributed actions with the help of logical clocks [Lam78]. Normally, a schedulerdecides how to execute the actions or how to detect and repair order inconsistencies.The following serialization approaches can be distinguished [GM94]:

1. Non-optimistic serialization ensures that all distributed actions are executedin the same order at all participating sites. For this purpose, the schedulerensures that only one distributed action is executed at a time.

2. Optimistic serialization is based on two assumptions. First, it assumes thatinterfering distributed actions are rarely executed out of order. Secondly, itassumes that it is more efficient to proceed with the execution and then repairthe produced problems than to guarantee a correct order. One approach torepair the produced problems is to roll back the state of the shared data toits state just before the out-of-order action happened and then re-execute theactions in order. Examples for this approach are the ORESTE [KBL93] andTimewarp [Edw97] algorithm. Another approach is to transform an out-of-order distributed action with a set of rules so that its effect is the same as ifit is received in order. Sun and Ellis [SE98] give an overview and evaluationabout existing approaches. They, e.g., discuss the well-known dOPT -algorithm[EG89].

The non-optimistic approach can disturb the interaction among the users. Theoptimistic approach can confuse a user by rolling back or transforming a modifica-tion. Furthermore, the implementation of a roll back mechanism is very memoryintensive, as the state of an application has to be stored. Sometimes it can even beimpossible or at least very expensive to define the rules that are needed for the trans-formation. In the dOPT-algorithm, e.g., a developer has to define a transformationfor each pair of actions.

Concurrency control through locking requires that a site requests and receives adistributed lock before it executes a distributed action. The lock can have differentgrain sizes. The grain size of a lock determines how much of a shared data object


or all shared data objects can be modified after getting one lock. It is a difficultissue to set the grain size of a lock. A coarse grain size reduces the number of lockrequests, but also the concurrency in the application. A fine grain size increasesthe number of lock requests and the network traffic, but improves the concurrencyin the application. Similar to the different serialization approaches, Greenberg andMarwood [GM94] distinguish different locking approaches:

1. Non-optimistic locking enforces a site to wait until the requested lock is grantedbefore it is allowed to execute a distributed action.

2. Optimistic locking can be compared with optimistic serialization. A site re-quests the lock for a distributed action, but does not wait until the lock isgranted to execute the action locally. When the lock is granted, nothing hasto be done. Otherwise, the action has to be rolled back.

Concurrency control through locking has almost the same drawbacks as con-currency control through serialization. The non-optimistic approach can disturb theinteraction of users, as a user can be blocked during his work. The optimistic schemesuffers from the problem to roll back or transform an action.

Especially optimistic approaches are highly application-specific, as the applica-tion has to support the roll back of an action or the transformation of interferingactions, which is not always possible. All presented approaches have drawbacks.Roseman and Greenberg [RG96a] state that the concurrency control needs are highlyapplication-specific and that there is no generic method to ensure the consistencyof the shared data objects. Different applications and even single applications havedifferent requirements concerning data consistency and how consistency is achieved.For this reason, the following requirements must be fulfilled:

R15: Developers must be able to choose among predefined concurrency controlschemes.

R16: Developers must be able to define the concurrency control scheme per sharedobject.

Even if a platform offers a set of predefined concurrency control schemes, thesemay not meet the requirements of all groupware applications. For instance, considerthe different policies for floor control. This leads to the further requirement:

R17: Developers must be able to configure the predefined concurrency controlschemes and to introduce their own ones.

2.2.5 Data Persistency

Prakash et al. [PSL99] postulate a support for synchronous and asynchronous collab-oration. Users may require several sessions to accomplish their goals and they maynot be able to schedule a common time for synchronous collaboration. For instance,


imagine a group whose members live in different time zones. For such a group, it ishard to find a time at which all members can participate in a collaborative session.Normally, it is also difficult to cooperate for a long time.

DreamTeam is based on the session metaphor and thus concentrates on syn-chronous collaboration (see section 2.1). However, the above example shows thatusers must be able to store states for a later resume of the collaborative work andthat users must be able to prepare data for later use in a session. Therefore, thefollowing requirement must be met:

R18: A persistency service must enable a transition between synchronous andasynchronous collaboration.

For a transition between synchronous and asynchronous collaboration, a devel-oper must be able to implement application functions that allow a user to preparedata for a later session. Thus, the persistency service must fulfill the followingrequirement:

R19: Developers must be able to store and load shared data objects.

The room metaphor relies on a well-known server. As soon as this server be-comes unavailable, a group cannot resume collaborative work. However, it shouldbe possible for a group to resume work at any time. This leads to the followingrequirement:

R20: The persistency service must not rely on a well-known server.

2.3 Summary

This thesis takes DreamTeam as a starting point. DreamTeam just offers a rudi-mentary support in the data domain of the programmer-centered clover model. Thedata domain is divided into four sub-domains: data distribution, data consistency,concurrency control, and data persistency.

In our opinion, the development of groupware applications should be almost aseasy as the development of single-user applications. To achieve this, a platform hasto offer services in the data domain. This chapter determined the requirements inthe different sub-domains of the data domain. An ideal platform has to meet allthese requirements.

The offered services have to relieve a developer from all data sharing issues. Adeveloper should be able to use a shared data object almost like a data object ina single-user application. Thus, the services have to achieve a maximum of trans-parency. The discussions about the data distribution and the concurrency controlshowed that there is not one solution that fits for all groupware applications. Thus,the respective services have to be flexible and extensible. If this is achieved, adeveloper can concentrate on application-specific details.

2.3. SUMMARY 25

However, even if a platform fulfills all determined requirements, it can still bedifficult to develop a collaborative application. Developers may not be sure, how todevelop groupware or how to use the services that a platform offers. To overcomethis situation, the following requirement must also be fulfilled:

R21: Developers must be provided with a methodology to develop groupwareapplications.

Before the following chapters describe, which approach is taken in this thesis tomeet the requirements summarized in table 2.1, the next chapter discusses existinggroupware platforms and examines which requirements they meet.


R1 Developers must be provided with services concerning data distribution,data consistency, concurrency control, and data persistency.

R2 Developers must be able to use shared data objects transparently.R3 Developers must not be restricted during the implementation of shared data

objects.R4 A collaborative application has to be divided in data objects and user in-

terface objects.R5 A notification service must inform interested objects, whenever a shared

data object changes.R6 Developers must be able to define the distribution scheme per shared object.R7 Developers must be able to choose between an asymmetric, a replicated,

and an adaptive distribution scheme.R8 Developers must be able to configure the predefined distribution schemes

and to introduce their own ones.R9 A set of distributed actions must transparently handle shared state changes

as well as accesses.R10 The effects of different distribution schemes concerning nested shared state

changes as well as accesses must be considered.R11 A user or site that becomes unavailable must not affect the consistency and

availability of the shared state.R12 A platform-provided latecomer support must relieve the developer.R13 Latecomers must be able to choose, if they want to join with a replay or

with a direct state transfer.R14 A concurrency control service must ensure a correct execution order.R15 Developers must be able to choose among predefined concurrency control

schemes.R16 Developers must be able to define the concurrency control scheme per

shared object.R17 Developers must be able to configure the predefined concurrency control

schemes and to introduce their own ones.R18 A persistency service must enable a transition between synchronous and

asynchronous collaboration.R19 Developers must be able to store and load shared data objects.R20 The persistency service must not rely on a well-known server.R21 Developers must be provided with a methodology to develop groupware

applications.

Table 2.1: Summary of requirements

Chapter 3

Related Work

For collaboration-aware as well as for collaboration-transparent applications a lotof supporting platforms exist. Notable platforms for collaboration-transparent ap-plications are MMConf [CMB+90], XTV [AWF91], HP SharedX [GWY94], andJAMM [BRS99]. As already argued, it is difficult for these platforms to supportcollaboration-awareness. If collaboration-awareness is not supported, it is difficultto facilitate coordination and to establish a social space, as other group membersare not physically present at the same place.

DreamTeam (see section 2.1), the starting point for this thesis, focusses on thedevelopment of collaboration-aware applications. Therefore, this chapter only con-siders platforms that also support the development of collaboration-aware applica-tions. A feature to distinguish such platforms is the way how they distribute thestate of a collaborative application. Some possibilities are a central, a replicated, ora partially-replicated distribution scheme. Some platforms offer a variety of distribu-tion schemes. The following sections describe sample platforms for every distributionscheme.

3.1 Central State

In the central state architecture, a well-known server manages the data of an appli-cation. The main advantages of this distribution scheme are that it is quite simple toensure data consistency, to handle persistency, or to accommodate latecomers. Themain drawbacks are that a server must be maintained, the server is a bottleneck,and that slow network connections can increase the response time of an application.However, the following groupware platforms chose the central state architecture.

NSTP

The Notification Service Transfer Protocol (NSTP) [PDK96] provides a service fordata sharing in synchronous multi-user applications. The service is offered by a well-known notification server. The server provides clients access to a shared state andnotifies these clients, whenever the shared state changes. The server contains twokinds of objects: places and things. A place contains the shared state and partitions

27

28 CHAPTER 3. RELATED WORK

the resources of the server among several applications. Each application uses at leastone place. A client joins a collaborative application by entering the place. Thingsare the actual objects that maintain the shared state. They consist of a name,value, and attributes. The value is a byte array. The attributes determine thekind of notification that a changing thing causes. Things can be created, changed,locked, unlocked, and deleted. As the server has no understanding of the applicationsemantics and handles the shared state as a byte array, the client is responsible forthe semantics and processing, e.g. to encode and decode the byte array. This impliesthat NSTP does not support incremental updates, as each update overwrites the oldvalue of a thing.

Rendezvous

Rendezvous [Pat91, HBR+94] is primarily designed for building synchronous group-ware applications. Rendezvous is based on the application scheme ALV [Hil92].Thus, an application that is implemented using Rendezvous is split up into abstrac-tions, links, and views. Abstractions contain the shared state of an application.Views present individual users with user interface representations and interactionmechanisms. The links are responsible for applying user interface actions to theabstractions and to update views when the abstractions change. Rendezvous placesboth the abstractions and the view on a single processor (see fig. 3.1). So the ab-stractions always contain the correct state of an application. It was considered toadapt Rendezvous to other distribution architectures [HBR+94], but implementa-tions were never completed. Thus, users of the Rendezvous system suffer from thedrawbacks of a centralized state, e.g. low response time etc.

UNIX Process

Shared

abstraction

View View View

Graphics

Links

Network

Figure 3.1: Architecture of Rendezvous [HBR+94]

3.1. CENTRAL STATE 29

Suite

Suite [Dew90, DC92] is a flexible toolkit for the development of editor-based userinterfaces. Suite applications are split up in active variables and dialogue managers(see fig. 3.2). Active variables contain the state of a collaborative application andare centrally maintained. The dialogue managers are replicated. They display theshared state and handle the user interaction. To improve the response time of theapplication, each dialogue manager maintains a cache, which keeps replicas of theactive variables. Suite offers primitives that a developer can use to create or todelete variables and to set or to retrieve values. Suite locks a variable whenever it ismodified to ensure consistency. Thus, users cannot modify a variable concurrently.As this can be too restrictive for some applications, a developer can override thedefault mechanism.

Coupling

Dialogue

manager

Editable object

Dialogue

manager

Shared

active

variable

Interaction

variable

Interaction

variable

Figure 3.2: Architecture of Suite [DC92]

Summary of Deficits

The above platforms leave it to the developer to distribute state changes and thus donot achieve transparency (R2, R9, and R10). Additionally, none of the above plat-forms allows developers to choose between different distribution schemes or adaptthe distribution to specific needs (R7, R6, and R8). The same applies to the con-currency control domain of the programmer-centered clover model (R15, R16, andR17). As the platforms rely on a well-known server, the shared state becomes un-available as soon as the server goes down (R11). Though the server enables a simplelatecomer accommodation, none of the platforms allows the latecomer to choose howhe wants to join a session (R13). Finally, none of the above platforms considers datapersistency (R18).


3.2 Replicated State

In the replicated state architecture, the data of an application is distributed to allor in some variants to a subset of all participating sites. A lot of platforms use thereplicated distribution scheme, as an application can access the shared data locallyand this reduces the response time. Especially for interactive applications, this isan important issue. However, as already discussed in [GM86], the runtime systemhas to use more complex algorithms, e.g. for concurrency control, and the networktraffic to keep the shared data consistent increases. This section introduces someplatforms that rely on this distribution scheme.

Habanero

Habanero [CGJ+98] is a groupware platform implemented in Java. It focuses onmaking Java applets available in a distributed environment. The applets must beavailable as source code and in most cases can be converted into a distributed applet(called Hablet) without too much effort. The state of a hablet is replicated to everyparticipating site. To keep the shared state consistent, Habanero intercepts userinterface events and forwards them to a well-known server. The server examines theevent to determine, whether it is legal or illegal. This allows a central check againstprogrammers, who rewrite application code to perform illegal actions. Illegal actionsare discarded, and legal actions are forwarded to all clients. As the server serializesthe events, it ensures state consistency and simplifies shared data management.However, like in the central state architecture, the central server is a bottleneck andincreases the response time of a hablet.

GroupKit

GroupKit is a toolkit for building real-time collaborative applications. The first gen-eration [RG92, RG93] was implemented in the C++ on top of the InterViews toolkit.Based on the experiences with the first generation, a second one [RG96a, GR99] wasimplemented with Tcl/Tk. The runtime system of GroupKit actively manages thecreation, location, interconnection, and teardown of distributed processes. Addi-tionally, it sets up communication links between the participating sites and providesgroupware specific features such as session management. Fig. 3.3 shows the run-time architecture and process model of GroupKit. Each box represents a differentworkstation. The ovals are instances of processes running on each machine, and thedirected lines joining them indicate communication paths. The registrar is a cen-tralized process that acts as a connection point for a community of conference users.The session manager is a replicated process that lets users, e.g., join and leave asession. A conference application is a replicated GroupKit program that is invokedby the user through the session manager.

In GroupKit, a developer has to be aware of the distributed environment. Forthis purpose, GroupKit offers some programming abstractions, e.g. multicast RPC[RG97a] or a shared data model called environment [Ros95]. The multicast RPCallows a developer to distribute a procedure call to all participating sites and so

3.2. REPLICATED STATE 31

Conference

A

Registrar

Session

manager

Conference

B

Session

manager

Conference

A

Conference

B

A "well-known" server

Figure 3.3: Runtime architecture and process model of GroupKit [GR99]

achieve view synchronization. An environment allows a developer to achieve statesynchronization.

An environment is a hierarchical data structure, where a node either can hold avalue or have other nodes as children. Nodes are referred to by a key. The runtimesystem transparently replicates an environment. A developer can bind callbacks toan environment and receive a notification when a node is added, changed, or re-moved. For the consistency of an environment, a developer can select a predefinedconcurrency control scheme (none or serialization via a central server). Greenbergand Marwood [GM94] are of the opinion that there is no generic method for con-currency control. Thus, a developer can define his own concurrency control scheme.

COAST

COAST (COoperative Application Systems Toolkit) [SKSH96, KS97, SSS99] is anobject-oriented groupware platform. It is implemented in Smalltalk and offers de-velopers classes that support the development of collaborative applications. Eachapplication manipulates one document. The document is fully replicated. A docu-ment consists of document parts which can have an arbitrary object structure. Adeveloper has to subclass the abstract COAST replicated object class to implementa document. On the one hand, this object class hides the issues concerning datareplication and consistency. On the other hand, a developer cannot reuse existingdata classes by inheritance.

Fig. 3.4 shows the architecture of a COAST application process. The architec-ture can be compared with the application scheme MVC [KP88]. A session objectcoordinates how a user accesses a shared document. View and controller allow auser to interact with the shared document. A session manager allows a user tocreate, join, or leave sessions. User objects represent concurrent users of the doc-ument. A shared document is modified with transactions. A transaction managerensures the integrity of the shared document. A replication manager is responsi-ble for synchronizing the replicated objects. For this purpose, COAST uses theoptimistic concurrency control scheme DOCC that is based on ORESTE [KBL93].An arbitrary site of all sites that hold a replicated document is responsible for the


persistency of the document.

Replication manager

Network

Document

part User object

Session

manager

View

Information flow

Reference

Controller

Session

object

Transaction

manager

Figure 3.4: Architecture of a COAST application process [SKSH96]

DAgora

DAgora [SDMP97, SPDM97] is an object-oriented groupware platform that supportssynchronous as well as asynchronous groupware. In DAgora, the shared state ispartially-replicated, i.e. the shared state is distributed to more than one site, butnot necessarily to all sites. DAgora uses the peer object-group design pattern toimplement this distribution scheme: each site holds a replica of every object thelocal user is currently working on. The set of replicas for an object is called a peerobject-group. To access a replicated object, a developer has to join the respectiveobject-group. When he is no longer interested, he can leave the object-group. Fig.3.5 illustrates the peer object-group design pattern.

DAgora provides an object-oriented framework [PMDS98] that a developer has touse to define new data objects, i.e. he has to extend a framework-provided basic dataclass. Like in COAST, it is not possible to reuse existing data classes. Additionally,he has to tag the methods that modify the content of the data object with a specialqualifier. DAgora preprocesses the developer-defined data class and so achievestransparency for the developer. A developer can associate different concurrency

3.2. REPLICATED STATE 33

Large scale unreliable

network infrastructure

Process

address space

Process address space

Process

address space

Process address

space

Object group 1

Object group 2

Object group 3

Figure 3.5: Peer object-group design pattern in DAgora [SDMP97]

control schemes, e.g. one that is based on a total order of modifications or one thatuses an optimistic approach, with different data classes. Thereby, DAgora achievesconcurrency control flexibility.

Though DAgora first had the focus to support synchronous as well as asyn-chronous groupware, it now focusses on asynchronous groupware and offers a flexibleobject storage system that relies on multiple servers [PMDS99, PMDD00].

DyCE

DyCE (Dynamic Collaboration Environment) [TS00, Tie01] is a framework for thedevelopment of collaborative components, so-called groupware components. Group-ware components are visually interactive and collaboration-aware tools. They allowa user to access and manipulate shared data. Furthermore, they can be reused andcombined with other components.

DyCE is based on the client/server paradigm. The server consists of a sessionmanager, a component broker, an HTTP server, an object manager, and a trans-action manager. The component broker manages the registered groupware compo-nents. The HTTP server is used by the clients to download groupware components.The object manager maintains the persistent object storage and manages sharedobjects. In DyCE, a developer has to define a transaction to modify a shared dataobject. The transaction manager at the server is responsible for the concurrencycontrol of these transactions.

A client consists of a component desktop, a session manager, an object manager,and a transaction manager. DyCE uses a variant of the normal replication schemethat stems from the lazy replication approach [LLSG92]. DyCE does not replicate ashared object to a client before the client accesses it. Until then, the server maintainsa copy of every shared object that is currently used by a groupware component.


Transaction

manager

Component desktop

Component

Component Shared objects

Session manager

Object manager

Remote method invocation

Ne

two

rk

Session

manager

Component

broker

Transaction

manager

Object manager HTTP server

HTML

documents

Component

Repository

Object

storage

Clie

nt

Serv

er

Figure 3.6: System architecture of DyCE [TS00]

Thus, not all clients may have the same set of replicas and the object manager atthe client just maintains the current set of local replicas. As DyCE does not offer amechanism to discard a replica, the shared objects are fully replicated, as soon asevery client has accessed every shared object. However, until a shared data object isnot fully replicated, this replication approach reduces the communication costs, as,e.g., a modification of a shared data object need not be propagated to all clients.

Summary of Deficits

GroupKit and DyCE leave it to the developer to identify state changes and thus donot achieve transparency (R2 and R9). Compared to them, Habanero, COAST, andDAgora transparently handle state changes. However, COAST and DAgora requirethat shared data objects extend platform-provided classes. Thus the developer can-not reuse existing data classes and is restricted during the implementation of shareddata objects (R3).

None of the above platforms allows developers to choose between different dis-tribution schemes or adapt the distribution to specific needs (R7, R6 and R8).Additionally, none of the platforms explicitly addresses nested state changes (R10).

Despite of DAgora, none of the above platforms offers different concurrency con-trol schemes (R15). Habanero, GroupKit, and DyCE use a well-known server tohandle concurrency control. As soon as this server becomes unavailable, collabora-tion is impossible (R11).

Concerning latecomer support, none of the above platforms allows a latecomer

3.3. FLEXIBLE STATE DISTRIBUTION 35

to choose how he wants to join a session (R13).While Habanero and GroupKit do not consider data persistency (R18), COAST,

DAgora, and DyCE address persistency issues. However, in COAST and DyCE thepersistency service relies on a well-known server (R20).

3.3 Flexible State Distribution

The previous sections introduced some groupware platforms that rely on a specificdata distribution scheme. As already argued, none of the distribution schemes fitswell for every groupware application. Often, even a single application has differentrequirements concerning data distribution. The following sections introduce someplatforms that take this observation into account and offer a flexible data distribu-tion.

AMF-C

AMF-C [TBDP98] is an application scheme that can be viewed as a generalizationof ALV, PAC∗, or multi-user MVC. AMF-C defines each component of a collabo-rative application as an agent which consists of a variable number of facets. Theagents communicate with each other via messages. In principal, these agents can besplit across the network and thus a variety of distribution schemes is possible. How-ever, until now this approach was only validated in the groupware platform ECooP[TBDP98] that just supports a replicated state.

DistView

DistView [PS94] is a part of the Collaboratory Builder’s Environment (CBE)[PSL99]. The CBE provides a computer-based shared workspace to support scien-tists. DistView is based on a collaboration paradigm in which the sharing of viewsoccurs at the window level. Fig. 3.7 shows the runtime architecture of DistView.In order to share a window, a user first exports the window to a well-known sharedwindow server. After this, other users can import the window from the server. Ex-port and import window manager handle the state transfer between an exportingand importing site.

DistView divides an application into interface and application objects. Interfaceobjects allow users to interact with applications and application objects maintain theapplication data. When a user imports a window, DistView replicates all interfaceand application objects. DistView intercepts all calls to these objects and broadcaststhem to the respective replicas to synchronize the states of the shared windows. Todistribute state changes, DistView relies on the Arjuna system [LMS93, LS94]. TheArjuna system considers nested state changes.

DistView replaces all objects of an application with a proxy object that offersthe same interface to intercept calls. Proxy objects can easily be used as replacingobjects. Shapiro [Sha86] uses proxies in the context of a distributed system to controlthe access to local and shared data objects. Gamma et al. [GHJV95] introduce


Window

(private)

Window 1

(exported)

Window 2'

(exported)

Window

(private)

Window 1'

(exported)

Window 2'

(exported)

Export

window

manager

Import window

manager

Export

window

manager

Import window

manager

Shared window

server

State transfer

messages

State transfer messages

Figure 3.7: Runtime architecture of DistView [PS94]

proxies as design pattern and define a proxy as an object that is used as a surrogateor placeholder for another object to control the access to the latter one or to fulfilladditional tasks.

Sometimes not all application objects can be replicated, e.g., if an applicationobject accesses a file in the local filesystem. A developer has to indicate, whetheran application object can be replicated or not. If an application object cannot bereplicated, DistView creates a proxy object at the importing site. The proxy objectintercepts possible calls on the object and forwards it to the site where the objectresides. Thus, DistView supports a replicated and asymmetric distribution scheme.

Proxy objects achieve transparency for the developer. Unfortunately, theachieved transparency is reduced, as DistView requires that a developer requestsand releases appropriate locks to ensure the consistency of the application objects.Additionally, DistView requires that an application satisfies the auto-update prop-erty, i.e. it does not provide a notification service.

Clock

Clock [Mor94, GUN96] consists of an application scheme, a functional programminglanguage [GU96] and the visual programming environment ClockWorks [GMU96].

The application scheme is based upon MVC [KP88]. Thus, an application isdivided into the components model, view, and controller. The model contains thedata of the application and the corresponding algorithms to maintain the data aslong these are not related to the user interface. The view contains all functions thatare necessary to display the data. Finally, the controller accepts the user events andcreates further events that change the underlying model in correspondence to theaccepted user event.

Clock reuses some concepts of Weasel [GU92], an earlier system developed by


the same researchers. The main difference is that Weasel does not use a controller.Clock divides the implementation of a collaborative application in two parts.

First, a developer has to split up the application according to MVC and has toarrange the resulting components in ClockWorks. This results in a tree structure.The root of the tree represents the model of the application. A developer can asso-ciate annotations with the components of the applications. There are annotationsfor request caching, concurrency control, and the distribution scheme of the model[UG99]. A developer can choose between a central and a replicated distributionscheme for the model components of the application. The view is replicated to theparticipating sites. If a developer chooses the central distribution scheme for a modelcomponent, he can associate different request caching strategies with the model. Therequest caching can increase the system performance, as some remote requests canbe handled locally. Apart from the request caching, a developer can select betweentwo concurrency control schemes for the central distribution scheme: an optimisticand a pessimistic one. If a developer chooses the replicated distribution scheme, hehas to ensure the consistency of the model on his own.

After building the tree structure, a developer has to implement the functionalityof the components. For this purpose, he has to use the functional programminglanguage that Clock provides. Finally, a developer can test and run the application inClockWorks. By changing the annotations, he can evaluate different configurationsand find the one that fits best for his application.

Dragonfly

Dragonfly [AGW00] is an application scheme that divides a collaborative applicationinto Dragonfly components (see fig. 3.8).

View Controller

Mirror Cache

Sequencer

Model

Cache

Concurrency

Controller

Component Router

Dialogue Router

Model Router

Model Component

Dialogue Component

Figure 3.8: A Dragonfly component [AGW00]

Each component is split up in two sub-components: the dialogue and the modelcomponent. The dialogue component corresponds to a view/controller pair in MVC.The model component corresponds to the model in MVC. Each sub-component is


divided in facets that work in combination to achieve goals. The view controllerfacet and the model facet work in combination to provide MVC functionality. Themirror cache facet and the cache facet provide request caching. The sequencer facetand the concurrency controller facet provide concurrency control. The routers han-dle the message passing between the different facets. All facets follow the Dragonflyprotocol [And99] that specifies interfaces for the facets or defines message types forthe communication. The facets can be exchanged to provide flexibility. A currentimplementation of this application scheme is the toolkit TeleComputing Developer(TCD). TCD is implemented in Java. A Dragonfly component is represented by aJava bean [SUN97a]. A developer can use a visual component editor to construct acollaborative application from these beans. TCD offers different facet implementa-tions for a pessimistic and optimistic concurrency control scheme [Wri99], a centraland a replicated distribution scheme, and different caching strategies. The repli-cated distribution scheme is coordinated centrally, i.e. the complete inter-replicacommunication is routed through a well-known server. This reduces the advantagesof the replicated state. Until now, there are only discussions to introduce a dynamicdistribution scheme [Phi98].

Prospero

Prospero [Dou96b, Dou98] is a groupware toolkit that is implemented with the Com-mon Lisp Object System (CLOS). To add flexibility to the toolkit it heavily uses theprogramming technique open implementation [KLL+97] The main idea of open im-plementation is to identify a common interface for an implementation strategy andallow developers to realize and integrate their own strategy with the same interface.Thereby a toolkit developer can avoid two common problems that arise with normalblack box toolkits [Kic96]:

• Hematoma of duplication: A developer who uses a toolkit often re-implementsalready existing functionality as he is not aware of existing functionality.

• Coding between the lines : A developer uses undocumented and internal fea-tures of the toolkit to integrate new functionality into or to change the func-tionality of an existing toolkit

Prospero uses open implementation to provide a flexible distributed data[Dou95a, Dou95b] and consistency management [Dou96a]. The distributed datamanagement is based on the synchronization of streams of activity. A developer caninfluence the implementation of such streams and thereby influence how shared dataare distributed. Dourish states that most groupware platforms are based on incon-sistency avoidance instead of consistency management. A groupware platform thatuses inconsistency avoidance prevents parallel work with, e.g., distributed locks.The consistency management in Prospero synchronizes shared data after severalusers have worked on it in parallel. It allows the streams of activity to diverge andafterwards converges them. A developer can adapt the consistency management andso define arbitrary consistency schemes.


Dourish [Dou96b] illustrates his approach with some example applications thatuse different distribution and consistency schemes. For instance, he describes theimplementation of an editor that is based on a replicated distribution scheme and akind of shared database that uses a central approach. However, Prospero does notoffer any transparency. If a developer wants to influence the shared data manage-ment, he must be completely aware of the underlying concepts and, e.g., implementmethods to merge divergent replicas and restore consistency.

GEN

GEN [O’G96] is a prototypical groupware toolkit. It is based on distributed ob-jects and offers a lot of configuration possibilities concerning data distribution andconcurrency control. A developer can choose from predefined distribution and con-currency control schemes. A selected scheme is applied on a per-object basis insteadof per-application. For this purpose, GEN relies on the design pattern wrapper[GHJV93].

According to its definition, a wrapper attaches additional services, properties,or behaviors to another object. For this purpose, it encapsulates another objectinside itself and forwards requests to an encapsulated object. A wrapper can alsoperform additional operations before and after forwarding the request. GEN useswrappers to intercept method calls that are directed to a data object and to handlethe method calls according to the selected scheme.

A developer can implement data objects for a collaborative application in thesame way as for a single-user application. After creating an instance of a dataobject, he has to initialize a wrapper with the instance of the data object. As defaultimplementations, GEN offers wrappers for a replicated distribution scheme with andwithout concurrency control and an asymmetric distribution scheme. Additionally,GEN offers a wrapper for a distribution scheme that is based on migration. Thisdistribution scheme creates one instance of a data object. This instance migratesfrom one site to another site, if the new site accesses it more intensively. O’Gradyargues that this reduces the response time of the application at the new site.

To add even more flexibility, developers can create their own wrappers and specifyhow a data object is transferred between the participating sites, how method callsare routed between the participating sites, and how concurrency control is handled.Like Prospero, GEN achieves this flexibility by using the programming technique ofopen implementation. As a result, a wrapper distinguishes between different stagesthat a developer can modify. Fig. 3.9 shows these stages. Whenever a wrapperreceives a message, this message is passed through the different stages and appliedto the contained object. When the message passed all stages, the wrapper cangenerate a reply.

Like in Prospero, a developer has to be completely aware of the underlyingconcepts, if he wants to create a new distribution or concurrency control scheme,e.g. he has to handle the message exchange on his own. GEN does not consider datapersistency or discuss latecomer related issues. Additionally, it does not considercomposite shared data objects. However, as GEN offers default implementations, itachieves some transparency for the developer.


Wrapper Contained object

Pre-

notification

Pre-

concurrency

control

Post-

concurrency

control Post-

notification

Messages Replies

Figure 3.9: The use of wrappers in GEN [O’G96]

Summary of Deficits

Prospero leaves it to the developer to distribute state changes and thus does notachieve transparency (R2 and R9). DistView does not provide a notification service(R5).

Each of the above platforms allows a developer to define the distribution schemeper shared data object. Apart from AMF-C, a developer can choose between atleast two distribution schemes. None of the above platforms supports an adaptivedistribution scheme (R7). DistView and Clock are not extensible to further distribu-tion schemes (R8). In TCD, Prospero, and GEN, developers have to be completelyaware of data distribution issues, if they want to integrate their own distributionschemes. They cannot configure the existing distribution schemes, as postulated inR8.

DistView uses the Arjuna system to address the effects of nested state changes.However, as DistView only supports an asymmetric and a replicated distributionscheme, it just partly fulfills the requirement R10. The other platforms do notexplicitly address nested state changes.

While DistView does not support different concurrency control schemes, Clocksupports different concurrency control schemes for a central distribution scheme(R15). Prospero and GEN allow developers to influence the concurrency control,but again developers have to be completely aware of the underlying concepts andcannot configure the concurrency control (R17).

None of the above platforms explicitly addresses latecomer related issues (R12)and allows a latecomer to choose how he wants to join a session (R13). Additionally,none of the platforms supports data persistency (R18).

3.4 Summary

An ideal platform has to cover the complete data domain of the programmer-centeredclover model. For this purpose, it has to offer services for data distribution, dataconsistency, concurrency control, and data persistency. The offered services have torelieve a developer from data sharing issues, i.e they have to achieve transparency.Additionally, they have to be flexible, as, e.g., there is not one data distributionscheme that fulfills the requirements of all applications. Some of the presentedplatforms fulfill a part of these requirements, but none of them fulfills all.

3.4. SUMMARY 41

To achieve transparency, the presented platforms use quite different approaches.DistView uses proxy objects. DAgora and COAST require that a developer ex-tends platform-provided classes. Clock provides an own programming language andprogramming environment. GEN uses wrappers to hide data sharing issues. Allof these approaches transparently handle state changes. However, only DistViewpartly addresses the issues concerning nested state changes (R10).

There are platforms for every distribution scheme. As already argued, every dis-tribution scheme has its advantages and drawbacks. As different applications or evensingle applications can have different requirements, none of the distribution schemesfits well for every groupware application. For this reason, some of the presentedgroupware platforms support different distribution schemes, but none supports anadaptive distribution scheme (R7). Some of them, i.e. TCD, Prospero, and GEN,allow developers to introduce their own distribution schemes, if they are aware of theunderlying concepts, but none allows developers to configure the offered distributionschemes (R8).

Similarly, some platforms offer different concurrency control schemes and allowdevelopers to introduce their own concurrency control schemes. However, none of thediscussed platforms permits developers to configure the offered concurrency controlschemes (R17).

Finally, none of the presented platforms allows a latecomer to choose how hewants to join a session (R13) or provides a methodology on how to develop groupwareapplications (R21).

Chapter 4

Approach

DreamTeam (see section 2.1) entirely covers the coordination and communicationdomain of the programmer-centered clover model, i.e. an application developer neednot implement any functions of these domains himself. In the user interface domain,DreamTeam offers user interface components that can be used to provide collabora-tion awareness. In the data domain, DreamTeam just offers a rudimentary support.Thus, developers completely have to be aware of data sharing issues.

Chapter 2 determined the requirements in the data domain of the programmer-centered clover model. An ideal platform has to meet all these requirements. Theapproach taken in this thesis is to extend the DreamTeam platform with a plat-form, called DreamObjects, that offers services satisfying the determined require-ments concerning data distribution, data consistency, concurrency control, and datapersistency (R1). For integration in DreamTeam, DreamObjects has to be imple-mented in Java.

DreamObjects divides a collaborative application into data objects and userinterface objects (R4). Data objects are split in shared ones and private ones.The user interface objects control the user interface behavior of an application anddisplay the content of the data objects. Users collaborate by modifying shared dataobjects via the user interface of the application.

Developers should be able to use shared data objects almost like local data ob-jects of a single-user application. The platforms, presented in chapter 3, use quitedifferent approaches to achieve such a transparency. Several approaches were testedto achieve transparency in DreamObjects. Like in DistView, in a first approachDreamObjects used proxy objects [LU99]. Though proxy objects achieved trans-parency, the proxy object approach was rejected, as the development costs for ashared data object were too high. After rejecting proxy objects, DreamObjects re-quired, like DAgora and COAST, that developers extend a platform-provided classto implement shared data objects. Though this approach reduced the developmentcosts, it was later also rejected. As every shared data class has to extend a basic dataclass, a developer cannot reuse existing data classes by inheritance. Additionally,the basic data class defines the runtime characteristics of the data object, e.g. itsdistribution scheme. As the basic data class has to be defined at compilation time,it is not possible to adapt the characteristics of a data object to the runtime needs

43

44 CHAPTER 4. APPROACH

of a groupware application.As the final approach, DreamObjects now uses substitutes [LU00], which are

based on the substitution principle of object-oriented programming languages. Asubstitute class extends a developer-defined data class and overwrites some of itsmethods to add functionality for data sharing, e.g. the distributed actions formodifying and reading method calls (R9). At runtime, an instance of a substituteclass is used to replace the corresponding developer-defined data object. For thispurpose, a developer has to call a special registration method of the runtime sys-tem, which creates and returns the substitute to the developer. As a substitute classoffers the same interface as the developer-defined data class, developers can use aninstance of a substitute class like a local object (R2).

Fig. 4.1 shows the class hierarchy for a sample shared data object. This class hier-archy does not restrict a developer, when implementing shared data objects (R3). Adeveloper can reuse or generalize existing data classes by inheritance and implementcomposite data objects, as the class for a shared data object, e.g. SampleObject,just has

• to implement the SharedObject interface and

• to define a MODIFYING_METHODS field.

SORepresentation SampleSubstitute

«Schnittstelle»

SharedObject

«Interface»

+MODIFYING_METHODS

SampleObject

«Schnittstelle»

Substitute

«Interface»

Toolkit-provided class

Developer-defined class

Toolkit-generated class

Figure 4.1: Class hierarchy for a shared data object

The SharedObject interface serves as an identification for the runtime systemand does not require to implement any method. The MODIFYING_METHODS fieldspecifies the modifying methods of the data object. Later, the runtime system usesthis information to reduce the network load. Depending on the distribution schemeof a shared data object, some sites can execute reading method calls locally, whilemodifying method calls must be distributed to the other sites to keep the sharedstate consistent.

The substitute class implements the Substitute interface, which containssystem-specific methods. A developer can either generate the substitute class fromthe command-line interface or can leave it to the runtime system to generate thesubstitute class, when it is needed. Each substitute class contains an instance ofthe SORepresentation class. This instance contains the runtime configuration of ashared data object as specified during the registration of the shared object, e.g. its

45

distribution scheme and its concurrency control scheme. Thus, a developer can usethe same data class with different runtime configurations (R6 and R16).

Based on the substitute concept, DreamObjects offers services that fulfill thedetermined requirements. Chapter 5 describes a notification service that can be usedto couple the user interface with the shared data objects (R5). Chapter 6 presentsa configurable and extensible concurrency control service that ensures the correctexecution order of the state changes (R14-R17). The following chapters 7 and 8describe how DreamObjects handles shared state changes as well as accesses (R9 andR10). Chapter 9 introduces a persistency service that enables the transition betweenasynchronous and synchronous work (R18-R20). Chapter 10 describes a latecomersupport that leaves it to the latecomer if he wants to join a session with a replay or adirect state transfer (R12 and R13). Chapter 11 presents how DreamObjects fulfillsthe requirements concerning data distribution (R6-R8). Finally, chapter 13 combinesthe offered services to a methodology on how to develop groupware applications(R21).

46 CHAPTER 4. APPROACH

Chapter 5

Notification service

As required, DreamObjects divides a collaborative application in data objects anduser interface objects. This separation allows developers to reuse existing dataclasses and to implement different user interfaces with the same underlying data.As a result, the shared data objects can be manipulated unnoticed from a localapplication and an application must be able to react on remote changes. Therefore,DreamObjects offers a notification service that informs interested objects, wheneverthe shared state changes.

The shared data objects that an application uses form its shared state. Thisstate changes, whenever a shared data object is created or removed and whenevera method call modifies one of these shared data objects. DreamObjects offers twodifferent kinds of notification service to trace these state changes:

1. an event-based notification service and

2. a mapping-based notification service.

A developer can use these notification services to inform an arbitrary object, e.g.a user interface object, about state changes. This object is called listener. The event-based notification service informs the listener by passing an event that describes thestate change. The mapping-based notification service improves the event-based one.It restricts the passed information to the needs of a developer-defined listener objectand listener method. The listener method is only called, when a data object wasmodified in a way the call-listener is interested in. Thereby, developers can tailorthe number and the content of the notifications to application-specific needs.

Fig. 5.1 shows the principle of the notification service. Imagine that three userswork together in the CVE as described in section 2.2.1 and that the first user movesthe table. Each table is represented by a shared data object. Imagine, that thisshared data object is replicated to the three users. The corresponding method callchanges the local instance of the shared object. To keep the shared data objectconsistent, the method call is distributed to the other participating sites whichalso execute the method call. Each site associates a listener object with the localinstance of the shared data object for the table. After the method call was executed,the notification service informs the listener objects at the different sites. At each

47

48 CHAPTER 5. NOTIFICATION SERVICE

site, the respective local listener object displays the movement of the table in thelocal user interface.

User 1 moves

the table.

The local method

call changes the

data object.

The remote

method call

changes the data

object.

The remote

method call

changes the data

object.

The notification

service informs

the listener

object.

The notification

service informs

the listener

object.

The notification

service informs

the listener

object.

t

User 1 User 2 User 2

The listener

object displays

the movement of

the table.

The listener

object displays

the movement of

the table.

The listener

object displays

the movement of

the table.

Figure 5.1: Principle of the notification service

The following sections describe how the event-based and mapping-based notifi-cation service exactly work.

5.1 Event-based Notification

DreamTeam associates a list of applications, e.g. app1, . . . , appn, with every session.When a user starts a session, the runtime system starts all applications in this list.Each application is uniquely identified by an application reference. Let refapp denotesuch an application reference. Let Dapp denote the set of shared data objects of theapplication app and D the shared data objects of all applications.

Let classd denote the class of a shared data object d ∈ D. Each data objectd ∈ D offers a set of constructors Cd and a set of methods Md as defined by classd.The set MMd ⊆ Md denotes the subset of methods that modify the content of the

5.1. EVENT-BASED NOTIFICATION 49

data object. A method call of a data object d ∈ D is denoted by d.m with m ∈ Md,and a constructor call by d.c with c ∈ Cd.

The event-based notification service allows a developer to trace state changes tothe set of data objects D and to any data object contained in D. It distinguishestwo different kinds of listener objects:

1. An object-listener is informed by the runtime environment, whenever one ofthe participating sites creates a shared data object d, i.e. D := {d} ∪ D, orremoves one, i.e. D := D \ {d}.

2. A call-listener is informed, whenever a modifying method call d.m with d ∈ D

and m ∈ MMd is executed.

5.1.1 Object-listener

A developer must register object-listeners in the runtime environment by calling aspecial registration method. After an object-listener was registered, it is informed bypassing an object event, whenever the set of data objects changes. For this purpose,an object-listener has to implement an object-listener interface that is provided bythe DreamObjects class library. The interface demands the implementation of onelistener method. If a developer does not want to be informed anymore, whenever ashared object is registered, he can deregister the respective object-listener.

Let S denote the set of sites participating in a collaborative session. The runtimesystem of DreamTeam associates with every site s ∈ S a unique identifier ids. Asin DreamTeam only one client may run on a site, the number of sites, i.e. |S|,corresponds to the number of users in a session and the site identifiers also uniquelyidentify the users. The site identifiers are totally ordered: idsi

< idsjdenotes that

si ∈ S has a lower identifier than sj ∈ S.An object event consists of

• the created or removed object d,

• the identifier ids for the site s ∈ S that created or removed the object, and

• a value that indicates, whether the object was created or removed.

With the help of object-listeners, a developer can ensure that the applicationis informed, whenever a site changes the set of data objects D. He can use thiskind of notification service to, e.g., display the content of the new data object d.The identifier ids permits a developer to determine the site and thus the user whocreated d. He can, e.g., use this information to implement awareness services. Thelog window of the CVE uses an object-listener to display a message, whenever a useradds a new piece of furniture to a room.

5.1.2 Call-listener

Call-listeners have to implement a call-listener interface that is provided by theDreamObjects class library. The interface demands the implementation of one lis-tener method. Like object-listeners, call-listeners must be registered in the runtime


environment by calling a special registration method. In any case, a developer hasto pass the listener object as an argument to this registration method. After this hecan decide, if the call-listener listens to changes that are applied to

• a particular data object d ∈ D or

• all data objects of a particular class.

In the first case, he has to pass the data object d ∈ D to the registration methodand the call-listener is informed, whenever d changes. Let nameclassd

denote thename of a class classd with d ∈ D. In the second case, a developer has to passthe name of a class to the registration method and the runtime system informs thecall-listener, whenever a data object of the specified class changes. This is useful,when an application is interested in all changes that are applied to all instances of aspecific data class. The map of the CVE, e.g., registers a call-listener for each dataclass that represents a piece of furniture.

Each site maintains a set of call-listeners CLm for each modifying method m ∈MMd of a shared data object d ∈ D. If a developer registers a call-listener thattraces the changes of a particular data object d ∈ D, the runtime system adds thenew call-listener to each set CLm with m ∈ MMd. If a developer registers a call-listener that traces the changes of all data objects of a particular data class, theruntime system adds the call-listener to all respective call-listener sets.

Whenever a method call d.m with m ∈ MMd is executed, the runtime systemchecks the corresponding set CLm and informs all contained call-listeners. For thispurpose, it calls the listener method that is required by the listener interface andpasses a method call event as argument to this method.

Table 5.1 shows the content of a method call event for a method call d.m. Letnamem denote the name of a method m ∈ Md, Ad.m the tuple of method callarguments used for a method call d.m, rd.m its result, and sd.m ∈ S the site thatinitiated the method call d.m.

d The data object that was modified.

namem The name of a method m ∈ Md.

Ad.m The arguments of the method call d.m.

rd.m The result of the method call d.m.

idsd.m The identifier of the site that initiated d.m.

Table 5.1: Method call event

In the listener method, the event must be processed. With the contained dataobject d and the name of the method namem, he can decide if he is interested in theevent. For instance, consider a call-listener that is only interested in the movementof a piece of furniture in the CVE. If the name of the method is different to thename of the move method, the call-listener can discard the event. If the call-listeneris interested in the event, he can use the arguments of the method call Ad.m and itsresult rd.m to display the movement. The site identifier idsd.m is useful for awareness

5.2. MAPPING-BASED NOTIFICATION 51

purposes. It can be used to determine the user who changed the data object and,e.g., display who moved a table.

Finally, if a developer is not longer interested in tracing the changes of an objectd ∈ D or the changes to a specific type of data objects, he can deregister therespective call-listener. In this case, the runtime system removes the call-listenerfrom all call-listener sets.

5.2 Mapping-based Notification

Using the event-based notification service, a call-listener is informed, whenever amodifying method of the data object was executed. If a call-listener is not interestedin every modification, it receives a lot of unnecessary events. After receiving themethod call event, a call-listener has to figure out which method was called and todecide whether it is interested in the event or not. Myers [Mye91] states that thisoften leads to huge conditional code blocks that are not easy to maintain.

If a developer is not interested in tracing all changes that are applied to a partic-ular data object or a data object of a specific class, he can use the mapping-basednotification service of DreamObjects. This restricts the passed information to theneeds of a developer-defined listener object and listener method. The listener methodis only called, when a data object was modified in a way the call-listener is interestedin. This avoids the conditional code blocks and improves the maintainability of anapplication.

To use the mapping-based notification service, a developer has to register a lis-tener configuration in the runtime environment. This configuration defines whichdeveloper-specified listener method has to be called, when a developer-specifiedmodifying method of a shared data object was executed. If a developer is not longerinterested in tracing the changes of an object, he can deregister the configuration.

Again, a developer can decide, if he wants to listen to changes that are applied toa particular data object d ∈ D or to all data object of a particular class. In the firstcase, the listener configuration consists of a call-listener object cl, a listener methodml, a modifying method m ∈ MMd, and a data object d ∈ D. In the second case,the listener configuration contains the name of a data class nameclassd

instead of adata object. In both cases, the listener configuration contains a developer-definedmapping. This mapping defines which arguments are passed to the listener-methodml. Thus, it restricts the passed information about a method call d.m to the needs ofthe call-listener object cl. The arguments for the listener method ml can be selectedfrom:

• the method call arguments Ad.m,

• the shared data object d,

• the method call result rd.m, and

• the identifier for the method calling site idsd.m .


When a developer registers a listener configuration for a modifying methodm ∈ MMd, the runtime system adds the corresponding call-listener cl with itsconfiguration to CLm. When a developer deregisters a listener configuration, therespective call-listener is removed from the set CLm.

Figure 5.2: The configuration dialog for the log window of the CVE

To illustrate how the mapping-based notification service can be used to restrictthe passed information to the needs of the listener object, consider the log windowof the CVE as described in section 2.2.1. A user can define which modifications arelogged. Fig. 5.2 shows the respective configuration dialog. Currently, the log windowonly displays log messages, when the user ”Joerg” moves a wardrobe in the room”Three”. To restrict the notifications according to the configuration, the log windowuses the mapping-based notification service. Depending on the configuration, the logwindow registers itself as call-listener. For each possible log message, the log windowuses a different listener method and thus splits up the conditional code block. Thus,the call-listener configuration for the log configuration in the fig. 5.2 consists of

• the log window as listener object,

• the listener method that displays the log message for wardrobe movements,

• the move method of the wardrobe,

• the class name of the wardrobe class,

• and a mapping that selects the method calling site as the argument for thelistener method.

The listener method has to check, if the wardrobe is in the specified room andthe site identifier is the one for the specified user. In this case, the listener methoddisplays a log message, otherwise, nothing has to be done. When the log windowwould use the event-based notification service, it first had to check, what kind of fur-niture was modified, how it was modified, where it was modified, and who modifiedit. Thus, besides improving the maintainability, the number of checks is reduced.

Chapter 6

Concurrency Control

This chapter describes the concurrency control service of DreamObjects. As alreadydiscussed in section 2.2.4, there exists a lot of approaches to ensure the consistency ofshared data objects. These approaches range from the simple social protocol, whichdoes not need any platform support in the data domain, over floor control mecha-nisms, which involve the developer and the user, to either pessimistic or optimisticserialization mechanisms.

All presented approaches have drawbacks. Different applications have differentrequirements concerning data consistency and how consistency is achieved. In prin-cipal, it depends on the kind of application, which concurrency control mechanismfulfills the requirements.

DreamObjects offers a flexible concurrency control service. The service offers twopredefined concurrency control schemes: an object-based and a method-based one.With the object-based one a developer can implement floor control mechanisms.With the method-based one a developer can achieve a maximum of concurrency.Additionally, a developer can extend and adapt the service to application-specificneeds. For this purpose, DreamObjects uses a programming technique similar toopen implementation. The following sections in detail describe the predefined con-currency control schemes and how a developer can extend and adapt the concurrencycontrol service.

6.1 Object-based Concurrency Control

When a developer creates a shared data object, he has to define which kind ofconcurrency control scheme the object uses. Based on this, the runtime systemconfigures the shared data object.

For the object-based concurrency control scheme, the runtime system createsone distributed lock that is associated to the shared data object. This lock can becompared with the floor. Let fd denote the floor for a shared data object. Whoeverowns fd, can manipulate the shared data object, i.e. execute a method call d.m withm ∈ MMd.

There exist a lot of policies to pass the floor among the participants of a collabo-rative session. DreamObjects implements the basic request policy. For this purpose,

53

54 CHAPTER 6. CONCURRENCY CONTROL

DreamObjects offers two methods to request the floor and one method to release it.One of the methods to request the floor is blocking, i.e. when a developer requeststhe floor with this method, the method blocks the current execution, until the siteowns the floor. The other method to request the floor is non-blocking. A developercan pass a floor listener object to the request method. This listener object has toimplement a special interface that demands the implementation of one method thatis called as soon as the site receives the floor.

Before a site can execute a modifying method of a shared data object that usesthe object-based concurrency control scheme, the runtime system checks, if the siteowns the floor. If the site owns the floor, the method call is executed. Otherwisethe runtime system reports an exception and aborts the execution of the methodcall. This is done for the following reasons:

1. The shared data object could get inconsistent.

2. The developer would never know when a method call was not executed.

3. During the test phase of an application, this feature helps the developer toensure that he requests the floor before executing a modifying method call.

6.2 Method-based Concurrency Control

The method-based concurrency control scheme is based on non-optimistic locking.Its basic idea is to execute conflicting method calls under distributed mutual exclu-sion. Obviously, this guarantees the consistency of a shared data object.

Usually, not all modifying method calls are conflicting, as they do not changethe same attributes of the shared data object. To permit a concurrent executionof non-conflicting method calls, DreamObjects uses multiple distributed locks. Adeveloper can configure the grain size of these locks, i.e. how much of a shared dataobject can be modified by requesting one lock. Thereby, he can achieve a maximumof concurrency.

DreamObjects supports composite data objects. For a developer, it is normal tonest method calls in composite data objects, i.e. to call a method of a data objectfrom another method. For instance, consider the CVE. Whenever a table with alamp on top of it is moved, the move method of the table calls the move methodof the lamp. To ensure that the lamp stays in its position relative to the table, noother site is permitted to move the lamp, while another site moves the table. Thus,the method-based concurrency control need not only consider single shared dataobjects, but also dependencies between interacting shared data objects.

Briot et al. [BGL98] discuss different approaches for concurrency control in dis-tributed object systems. They also state that there is a need to distinguish between

• intra-object concurrency control that takes care of a single shared data objectand

• inter-object concurrency control that considers dependencies between interact-ing shared data objects.

6.2. METHOD-BASED CONCURRENCY CONTROL 55

DreamObjects supports both kinds of concurrency control. The following sec-tions describe how a developer can configure intra-object as well as inter-objectconcurrency control.

6.2.1 Intra-object Concurrency Control

A developer can specify which methods of a shared data object d ∈ D must notbe executed concurrently. For this purpose, he has to define subsets of Md. Themethods in such subsets are executed under mutual exclusion. By defining suchsets, a developer can configure which parts of a shared data object can be modifiedconcurrently.

Let EMj ⊆ Md denote an exclusive method set. All developer-defined ex-clusive method sets form the object exclusive method set denoted by OEMd ={EM1, . . . , EMn}. The set Ld = {l1, . . . , ln} contains all locks for a shared dataobject. The locks are totally ordered, i.e. l1 < l2 < . . . < ln. Each lock lj is assignedto exactly one set of exclusive methods EMj ∈ OEMd.

Whenever a site sd.m calls a method m ∈ Md, it requests all locks in the lock setMLd.m = {lj|m ∈ EMj ∧ EMj ∈ OEMd} for the method call d.m. DreamObjectsrequires that lock requests do not fail. Therefore, a token-based lock, e.g., has touse token-recovery mechanisms. However, it is still possible that deadlocks occur.To avoid them, the site sd.m requests the locks according to the order given by Ld.

Fig. 6.1 illustrates this approach that stems from resource allocation in operatingsystems [Hav68]. The figure shows a deadlock-free example lock allocation graphfor a shared data object d ∈ D with M = {m1,m2,m3,m4}, OEM = {EM1, EM2},EM1 = {m1,m3,m4} and EM2 = {m2,m3,m4}, and Ld = {l1, l2}. A directed edgefrom a method call d.mi to a lock lj means that the runtime system requested thelock lj for the method d.mi. An edge in the opposite direction means that d.mi

holds the lock lj. If d.m3 held the lock l2, there would be a cycle in the allocationgraph. Such a situation cannot happen because the locks are requested in sortedorder, i.e. the method call d.m3 must hold the lock l1 before requesting the lock l2.

d.m 1

l 1

l 2

d.m 2

d.m 3

d.m 4

Figure 6.1: Example lock allocation graph

6.2.2 Inter-object Concurrency Control

As already argued, inter-object concurrency control can be necessary, if there aredependencies between different data objects, e.g. remember the dependencies be-


tween a table and a lamp in the CVE. To ensure that the lamp stays in its positionrelative to the table, no other site is permitted to move the lamp, while another sitemoves the table.

Method call arguments can contain shared data objects. For some methods,it can be necessary that the method call arguments are not modified during themethod call. For instance, consider a method of a shared data object that calculatesan average value from a vector of shared data objects. This vector is passed asmethod call argument. To ensure, that this method has the same effect at everyparticipating site the shared data objects in the vector must not change during thecalculation.

Such inter-object dependencies mostly emerge at runtime, as shared data objectscan be added to another shared data object or can be passed in the method callarguments. Thus, a developer must be able to configure the inter-object concurrencycontrol at runtime.

The inter-object concurrency control configuration in DreamObjects consists oftwo parts. The first part is a mapping between

1. a method m ∈ Md of the shared data object and

2. an inter-object concurrency control method ioccm ∈ Md.

The method ioccm is called before a method call d.m with m ∈ Md is executed.The runtime system passes all shared data objects contained in the method callarguments Ad.m to the method ioccm. Based on this information, the method ioccm

has to return an inter-object exclusive method set IOEMd.m. The set IOEMd.m has tocontain the methods of other shared data objects that must not be executed duringthe execution of d.m.

The set IOEMd.m consists of exclusive method sets EMdi. Each set EMdi

containsthe methods of a shared data object di, which must not be executed by a sites 6= sd.m, while sd.m executes the method call d.m. A developer has to select this setsuch that

IOEMd.m ⊆ {EMdi|EMdi

⊆ Mdi∧ di ∈ D ∧ di 6= d}.

To use the inter-object concurrency control configuration for a method call d.m,the runtime system first determines the lock set MLd.m according to the intra-objectconfiguration of d. Then it evaluates the sets EMdi

∈ IOEMd.m. Based on the intra-object concurrency control configuration of di, the runtime system determines thelocks that are necessary to execute a method in EMdi

and adds these to MLd.m.Finally, the method call initiating site sd.m requests all locks in MLd.m per object di

according to the order defined by Ldi. So deadlocks are avoided again.

6.2.3 Example

To illustrate how these sets are used at runtime, consider the CVE as describedin section 2.2.1. Each artefact is represented by one shared data object, e.g. thedepicted table and the lamp on top of it. Let the shared data object for the tableoffer a set of four methods, which either move the table to another position, put

6.2. METHOD-BASED CONCURRENCY CONTROL 57

something on the table, change the appearance of the table, or resize the table.The following sets specify the intra-object concurrency control of the table:

• OEMtable = {EMpos, EMapp, EMsize}

• EMpos = {move, put}, EMapp = {change}, EMsize = {resize}

• Ltable = {lpos, lapp, lsize}

The methods change and resize can be executed concurrently, since they modifyindependent properties of the table. They are executed self-exclusively to allow onlyone user to change the corresponding property at a time. It must not be possibleto put something on a table, while the table moves and vice versa. Therefore, themethods move and put are executed exclusively.

Let a shared data object for a lamp offer a set of three methods, which eithermove the lamp, darken the lamp, or lighten the lamp. The following sets specifythe intra-object concurrency control of the lamp:

• OEMlamp = {EMlum, EMpos}

• EMlum = {darken, lighten}, EMpos = {move}

• Llamp = {lpos, llum}

As the methods darken and lighten modify the same property, they are exe-cuted exclusively. The method move is executed self-exclusively, as only one usershould be able to move the lamp at a time.

The shared data object for a table contains a list of all lamps that were put downon it. Whenever a table is moved, the respective move method also moves all lampson top of it. Without configuring inter-object concurrency control, the method callinitiating site would request the lock for the move method of a lamp on top the table,when the method is called and release the lock, after it finished. Thus, another usercould move the lamp during the movement of the table.

To prevent this, the CVE specifies an inter-object concurrency control configu-ration method ioccmove for the move method of the table. For the above example,this method returns the following inter-object configuration:

• IOEMtable.move = {EMlamp}

• EMlamp = {move} with move ∈ Mlamp

Because of the intra-object concurrency control configuration of the table, thelock set MLtable.move contains lpos ∈ Ltable. Due to the inter-object concurrencycontrol configuration, the lock set MLtable.move additionally contains lpos ∈ Llamp.After determining the lock set, stable.move requests the contained locks. As stable.move

now holds the necessary locks for the move method of the table and the lamp, noother site can move the lamp, before stable.move finishes the movement of the table.Thus, the specified inter-object configuration achieves the desired effect.


6.3 Extensibility and Adaptability

The last two sections described how a developer can use the two concurrency controlschemes to ensure the consistency of shared data objects. The offered concurrencycontrol schemes meet the requirements of most collaborative applications. However,if a developer needs a different concurrency control scheme or wants to use a differentdistributed lock, he can integrate his own implementation in DreamObjects.

6.3.1 Locks

Until now DreamObjects offers three different kinds of locks that can be used forthe concurrency control schemes

1. local semaphores, as known from operating systems,

2. Singhal’s token-based heuristically-aided algorithm for mutual exclusion[Sin89], and

3. Ricart’s and Agrawala’s optimal algorithm for mutual exclusion in computernetworks [RA81].

The local semaphores can only be used for shared data objects that use a centralor an asymmetric distribution scheme, as in this case the runtime system just hasto ensure that locally no exclusive methods are executed in parallel.

The two other locks can be used for all distribution schemes. Both locks toleratethat users dynamically join and leave a session. By default, DreamObjects usesSinghal’s algorithm when the participating sites are connected via TCP/IP, becauseit reduces the number of exchanged messages and thereby also decreases the responsetime of an application:

1. If a site holds a token, it can enter a critical section without requesting per-mission from other sites, like in, e.g., message based algorithms.

2. Singhal’s algorithm only requests permission to enter a critical section fromsites, which are supposed to hold the token.

DreamObjects uses Ricart’s and Agrawala’s algorithm when the participatingsites are connected via a network that supports IP multicasting. Compared toSinghal’s algorithm, this algorithm does not use a token that has to be requestedand received before a site can enter a critical section. Instead, it uses a logicalstructure that is updated by multicasting messages. As the algorithm relies onmulticasting, it works more efficient in multicast networks than Singhal’s algorithm.

There exist a lot of further distributed algorithms for mutual exclusion. Chang[Cha96] gives an overview and evaluation of available algorithms. If a developerneeds a different locking strategy, e.g. a priority-based one, or wants to realize adifferent floor control policy, e.g. a chair-guided one [DGLA97], he can define his ownlocking mechanism and integrate it into the runtime environment of DreamObjects.

6.3. EXTENSIBILITY AND ADAPTABILITY 59

Fig. 6.2 shows the class hierarchy of the different locking strategies thatDreamObjects offers. All locks are derived from a basic locking class that requiresto implement a request and release method that either request or release thelock. To define a new lock that is used for the asymmetric distribution scheme, adeveloper has to extend the LocalLock class. To define a new lock that can be usedfor all distribution schemes, a developer has to extend the DistributedLock class.After a developer defined his own locking mechanism, he can use it by just passingthe class name of the lock to the concurrency control scheme.

+request() +release()

Lock

SinghalLock RicartAgrawalaLock

LocalLock DistributedLock

Figure 6.2: Class hierarchy of the locks

6.3.2 Concurrency Control Schemes

DreamObjects offers an object-based and a method-based concurrency controlschemes. The object-based concurrency control scheme implements a floor con-trol mechanism with a basic request policy. The method-based concurrency controlscheme implements a non-optimistic locking approach. These are quite differentpolicies to ensure the consistency of a shared data object. Therefore, they cannotbe combined for composite data objects and composite data objects have to use thesame concurrency control scheme.

As discussed, the concurrency control needs are highly application-specific. If adeveloper, e.g., wants to use an optimistic locking approach or a different requestpolicy, he can implement a concurrency control scheme on his own and integratethis scheme into the runtime environment.

Fig. 6.3 shows the class hierarchy of the concurrency control schemes that areoffered by DreamObjects. Both, the method-based one as well as the object-basedone, extend the basic ConcurrencyControlScheme class. An instance of this classis contained in the configuration of each shared data object. If a developer wantsto implement a concurrency control scheme on his own, he has to extend this basicclass.

The basic concurrency control scheme class demands the implementation of thefollowing methods:

1. init: A developer has to use this method to initialize the concurrency controlscheme, e.g. the method-based concurrency control scheme uses this methodto create all necessary locks.


+preMethod()

+postMethod()

+lockObject()

+releaseObject()

+init()

ConcurrencyControlScheme

ObjectCC MethodCC

Figure 6.3: Class hierarchy of the concurrency control schemes

2. lockObject: The runtime system calls this method, if it wants to prevent othersites than the local one from executing a modifying method call that is directedto the associated shared data object, e.g. in the object-based concurrencycontrol scheme the associated floor is requested.

3. releaseObject: This method is called by the runtime system to allow othersites to modify the data object after it was locked.

4. preMethod: This method is called by the runtime system, before a method callis executed. In the method-based concurrency control scheme, this methodrequests the locks in the corresponding lock set for the method call. In theobject-based concurrency control scheme, this method checks, if the methodcall initiating site owns the floor and thus can modify the data object.

5. postMethod: This method is called by the runtime system after a method callwas executed. Thus, in the method-based concurrency control scheme thismethod releases requested locks.

These methods allow a developer to easily implement a variety of concurrencycontrol schemes. When a developer wants to implement an optimistic method-basedconcurrency control scheme, he can, e.g., use the preMethod method to request thelocks that are necessary to execute a method call. Instead of waiting until all locksare granted, the developer uses the postMethod method to check, whether the lockswere granted or not. When the locks were granted, he can directly release the locks,otherwise, he has to roll back the execution of the method call.

Chapter 7

Flat Distributed Actions

The set of shared data objects D forms the state of a collaborative session andthus the state of all applications that were started. A developer can modify theset of data objects by adding, by removing, or by modifying a shared data object.DreamObjects supports the following distributed actions that allow a developer toperform these modifications:

• Object registration

• Object duplication

• Object deregistration

• Modifying method call

• Reading method call

DreamObjects distinguishes between flat and nested distributed actions. Whileflat means that the distributed action does not initiate other distributed actions,nested means the opposite. The mechanisms that are used to handle nested dis-tributed actions differ from the ones for the flat distributed actions, as they, e.g.,have to respect the effects of composite data objects with different distributionschemes. They will be described in the next chapter.

For the necessary message exchange during the different distributed actions,DreamObjects relies on the network kernel interface (NKI) of DreamTeam (see sec-tion 2.1). The NKI offers services to establish and maintain network connections.Additionally, it allows to send, multicast, or receive messages. The services for themessage exchange are safe, i.e. messages do not get lost and are delivered in order.

7.1 Object Registration

At runtime, DreamObjects replaces developer-defined data objects with instancesof the corresponding substitute classes. Inside an application, a developer can usethe substitutes like local objects. For this purpose, a developer must implementthe classes for the shared data objects according to the class hierarchy in fig. 4.1

61

62 CHAPTER 7. FLAT DISTRIBUTED ACTIONS

and has to call a registration method of the runtime system to create the respectivesubstitute. The registration method

• generates the substitute class for the developer-defined data class,

• initializes and configures the shared data object according to the configurationthe developer provides,

• handles the mechanisms that informs all other participating sites about thenew data object, and finally

• returns the new data object.

7.1.1 Substitute Generation

Developers can either generate substitute classes on their own, i.e. from thecommand-line interface, or leave it to runtime system to generate the substituteclasses, when they are needed. However, to generate the necessary substitute class,the registration method calls the substitute generator that is provided by the run-time system of DreamObjects. The generation of the substitute class is dividedinto

1. an analysis,

2. a creation, and

3. a compilation phase.

In the analysis phase, the substitute generator determines the set of methodsMd and the set of constructors Cd. Then it checks, if the developer-defined dataclass respects necessary programming guidelines, e.g. a method in Md must not usea name of a system-specific method in the Substitute interface. If the substitutegenerator detects a violation of a programming guideline, it stops the generation ofthe substitute class and reports the violation to the developer.

In the creation phase, the substitute generator loads an initial source code for thesubstitute. This source code is included in the DreamObjects platform. It containsmethods common to all substitute classes, e.g. the methods that are specified by theSubstitute interface. Then the substitute generator adds a constructor for eachconstructor in Cd and a method for each method in Md to the source code. Theadded methods handle the method call distribution. The added constructors containcode to initialize the shared data object.

In the compilation phase, the substitute generator saves the generated sourcecode for the substitute class and compiles it. The resulting substitute class is loadedand added to the runtime environment.

7.1. OBJECT REGISTRATION 63

7.1.2 Initialization and Configuration

In the next step the registration method initializes and configures the substituteaccording to the developer-provided configuration. The configuration consists of

• the registration name,

• the constructor arguments,

• the concurrency control scheme,

• the distribution scheme,

• a persistency tag.

Registration Name

After a shared data object was registered, it is stored in a shared data object registrywhere it is identified by a shared data object reference refd. Let named denote theregistration name of a shared data object d ∈ D. The registration name is part ofthe reference and serves as an identification tag.

DreamObjects stores the data objects of all applications in one shared dataobject registry. To uniquely assign a shared data object d ∈ D to the applicationthat registered it, the reference refd additionally contains the application referencerefapp of the registering application.

A developer can specify the registration name named on his own or leave it tothe runtime environment to generate one. Normally, he leaves it to the runtimeenvironment, as it is only necessary to specify an own registration name, if it mustbe possible to request the shared data object from the runtime environment. Thisis, e.g., the case, when a latecomer joins a session. Then the session initiator hasalready started all applications that belong to the session. The applications havealready created the shared data objects that form the state of the session. Whena latecomer starts the application, the application must not create these shareddata objects again, but have to request them with the developer-defined registrationname.

A developer has to ensure that named is unique for the application that registersthe shared data object. This can be a problem. For instance, a developer can registera data object in a modifying method of another shared data object. As this methodmodifies the state of the application, it is distributed to the other participating sites.When the method is executed the first time, a developer can easily ensure that thename is unique for the application. The next time, the method is executed, thedeveloper must provide a registration name that is different from the one of the firstmethod execution. A simple approach could be to include a random or site-specificpart in the registration name, e.g. the current time or the network address of theregistering site. But each site that executes the method would register the newdata object with a different name. So normally, a developer leaves it to the runtimeenvironment to generate a unique name for a shared data object and thus overcomesthis situation. For this purpose, DreamObjects uses a runtime system-specific value


that uniquely identifies the shared data object registration at every participatingsite. The details of this value are described later in this section.

Constructor Arguments

Let Ad.c denote the tuple of constructor arguments used for a constructor call d.c.By specifying Ad.c, a developer can select the constructor that is used to initialize thedata object. The constructor arguments can also contain other shared data objects.Thereby a developer easily can build composite data objects.

Concurrency Control Scheme

By specifying the concurrency control scheme, a developer defines how the consis-tency of a shared data object is ensured (see chapter 6). As the concurrency controlscheme is defined at registration time and not at compilation-time, a developer canuse the same data class with different concurrency control approaches, e.g. in anapplication that relies on floor control and also in an application that optimizesconcurrency.

Currently, DreamObjects offers an object-based and a method-based concur-rency control scheme which cannot be combined for composite data objects. Thus,composite data objects have to use the same concurrency control scheme (see section6.3.2).

Distribution Scheme

DreamObjects supports a variety of distribution schemes, static and adaptive ones.Each distribution scheme is controlled by an instance of the Evaluator class. Whena developer registers a shared data object, he has to specify the evaluator and thusthe distribution scheme of the data object. Since the distribution scheme of anobject is defined at its registration, a developer can use different instances of thesame data class with different distribution schemes without any programming effort.A developer has also the possibility to define a distribution scheme on his own. Thedifferent distribution schemes and the tasks of an evaluator are discussed later inthis thesis (see chapter 11).

For now, let DHd ⊆ S denote the set that contains all data holders of an object.A site s ∈ DHd holds the data of an object and thus can perform method calls locally.Let sd ∈ S denote the site that creates a shared data object d ∈ D. Independentfrom the distribution scheme of a shared data object, the object creating site sd

becomes a data holder.

An evaluator for an adaptive distribution scheme dynamically changes the setof data holders, e.g. depending on how a user accesses the shared data object.DreamObjects offers two predefined evaluators for adaptive distribution schemes:

1. The user-oriented evaluator adapts the distribution of a shared data objectdepending on how a user accesses the shared data object.


2. The network-oriented evaluator adapts the distribution of a shared data objectdepending on the network that connects the participating sites.

If a shared data object uses one of the above evaluators, it is partially-replicatedto the participating sites and it is only known that sd ∈ DHd and DHd ⊆ S. Addi-tionally, to increase the availability of the data object these evaluators ensure that|DHd| ≥ 2.

The evaluators for static distribution schemes do not dynamically change theset of data holders, as this set is predefined. DreamObjects offers two evaluatorsfor static distribution schemes. The asymmetric evaluator sets DHd = {sd}. Thereplicated evaluator initially sets DHd = S and later ensures that every joining sitealso becomes a data holder.

Persistency

Finally, a boolean value defines, if the shared data object is persistent.DreamObjects offers services to store and load shared data objects as well as com-plete session states (see chapter 9). If a developer defines a shared data object aspersistent, he can use these services. By default, a shared data object is defined asnon-persistent.

As these services allow every participating site to store a shared data object,a data object that uses the asymmetric distribution scheme cannot be defined aspersistent. A developer should use a shared data object with an asymmetric distri-bution scheme to provide other sites access to site-specific data, e.g. a local file or adatabase. Thus, these data objects cannot be integrated in the persistency serviceof DreamObjects. If a developer defines a shared data object with an asymmetricdistribution scheme as persistent, the runtime system returns an error message.

7.1.3 Object Creation and Distribution

The distributed action that is used to create a shared data object and to distributeit to the other participants in the session is divided into five phases:

1. Initialization

2. Call-distribution

3. Call-execution

4. Concurrency Control

5. Post-execution

Initialization Phase

Before the site sd informs the other sites about the creation of the shared data object,it checks the configuration of the data object, e.g. if the specified registration nameis already in use or not. If the name is already in use, the registration method


reports an exception. Thereby, two shared data objects cannot be registered withthe same name.

After this, the runtime system at the object creating site sd creates the referencerefd. With the help of the reference, a shared data object can be uniquely identifiedin the distributed context. A reference consists of

• the identifier for the object creating site idsd ,

• the registration name named of the shared data object,

• a value that indicates what kind of distribution scheme the object uses,

• a boolean value that indicates if the object is persistent, and

• the reference of the object registering application refapp.

After creating the reference, the runtime system creates the representation repd

for the new object. Based upon the representation repd, every participating sitecan create an instance of the new data object. Fig. 7.1 shows the class hierarchyfor a representation. As depicted in the class hierarchy in fig. 4.1, each substitutecontains an instance of such a class. A representation consists of

• the reference refd for the shared data object,

• the constructor arguments Ad.c that were used to initialize the shared dataobject,

• the concurrency control scheme of the shared data object,

• the substitute class, if it was generated at runtime, and

• the evaluator of the shared data object.

SharedObjectReference

ApplicationReference

ConcurrencyControlScheme

SORepresentation

ConstructorArgs Evaluator SubstituteClass

Figure 7.1: Class hierarchy for the representation of a shared data object

After the object creating site sd created the reference and representation, itcreates a constructor call message that is later distributed to the other sites. At everysite, the runtime system maintains a logical clock according to [Lam78]. Whenevera site distributes a message to other sites in the session, it includes a timestamp,denoted by ts, and increments the value of the clock. A timestamp consists of thecurrent value of the clock at the sending site and the site identifier of the sending


site. Let ts.cv denote the value of the logical clock and ts.id denote the site identifierthat are contained in a timestamp ts. A timestamp ts1 is lower than a timestampts2, denoted by ts1 < ts2, if the clock value in ts1.cv < ts2.cv or, if these are equal,if ts1.id < ts2.id.

Whenever a site receives a message from another site, it extracts the includedtimestamp, compares it with the value of the local clock, and if necessary incrementsit to a value higher than the received one. As a timestamp uniquely identifiesa message, it, e.g., allows a site to determine, whether it has already received amessage or not. The timestamps define a total order of the received messages.

Table 7.1 shows the content of a constructor call message. Of course, it contains atimestamp tsd.c. When a developer did not specify a registration name, the runtimesystem uses a string representation of tsd.c as the registration name for d. Thistimestamp uniquely identifies the constructor call message and thus the new dataobject. The message also contains the representation repd to allow every receivingsite to create d. Finally, the message contains the identifiers for the sites thatbecome data holders of d. The site sd determined DHd with the evaluator for d,when creating the message.

tsd.c The timestamp of the constructor call message, i.e. a time-stamp of sd.

repd The representation of the shared data object.

{ids|s ∈ DHd} The identifiers of the sites that become a data holder of d.

Table 7.1: Constructor call message

Call-distribution Phase

In this phase, the object creating site sd distributes the constructor call message toall sites in S \ {sd}. The constructor call message requests all sites to create theshared data object d ∈ D.

Call-execution Phase

The class of every data object has to offer a default constructor, denoted by c0 ∈Cd, which has to create an empty instance of the data object. When a site s

receives a constructor call message, it checks, whether s ∈ DHd or not. If s ∈ DHd,the site executes the constructor as specified by Ad.c. Otherwise, it executes thedefault constructor c0. After executing the respective constructor each site initializesthe shared data object according to the developer-specified configuration, e.g. itinitializes the concurrency control scheme.

Concurrency Control Phase

Similar to constructor call messages, the runtime system distributes method callmessages to propagate state changes of a shared data object. Fig. 7.2 shows why


this phase is necessary. In this figure, three sites participate in a session. The boxesindicate the time for the constructor execution. The site sd

1 creates a new objectand distributes a constructor call message to the other sites. After executing theconstructor, the site s3 directly executes a method call on the new data object. Dueto network latencies, the site s2 receives the method call message without havingreceived the constructor call message and cannot execute the method call.

t t t

d.c 1

d.c 1

CC

CC: Constructor call message

MC: Method call message

MC

d .m

? d .m

d 1 s

2 s 3

s

Figure 7.2: Runtime failure during an object registration

To avoid such runtime failures, DreamObjects uses a two-phased protocol. Afterexecuting the constructor, all sites in S\{sd} send an execution confirmation message(see table 7.2) to the object creating site sd. As this message contains tsd.c, the sitesd can identify the object creation for which it received the execution confirmation.

ts The timestamp of the message, i.e. a timestamp of a site in S\{sd}.

tsd.c The timestamp of the constructor call message.

Table 7.2: Execution confirmation message

When the object creating site sd received a confirmation message from every site,it sends a registration permission message (see table 7.3) to all other sites. As thismessage contains the reference refd, the receiving sites can identify the object thatnow can be registered.

ts The timestamp of the message, i.e. a timestamp of sd.

refd The reference of the shared data object.

Table 7.3: Registration permission message


Post-execution Phase

In this phase, the object creating site sd registers the new data object. All othersites wait until they

1. either receive a registration permission message or

2. receive a message that is directed to the new data object, e.g. a method callmessage.

In both cases, the sites know that every site confirmed the creation of d and sentan execution confirmation message to the object creating site sd. A site can justaccess a registered data object and, e.g., execute a method call on a registered dataobject. So at least one site must have received the registration permission from thesite sd. Otherwise, it would not have been allowed to, e.g., execute the method call.

A site that registers a shared data object d stores it in the local object registry andinforms possible object-listeners about the new shared object. Furthermore, the sitechecks, whether it has to add some call-listeners to the sets CLm with m ∈ MMd ornot. If a developer registered call-listeners for changes applied to instances of classd,these call-listeners are added to the corresponding sets CLm.

Example

Fig. 7.3 shows an example for an object registration. Again, three sites participate ina session and the boxes indicate the time from the start of the constructor executionuntil the object registration. A hatched box indicates that the respective site is nota data holder.

t t t

d.c 1

d.c 1 �

�d.c

0 CC

RP

EC

RP

CC: Constructor call message

EC: Execution confirmation message

RP: Registration permission message

CC

EC

1 s d 2 s

3 s

Figure 7.3: Example for an object registration

In this example, the data object d uses an adaptive distribution scheme and thusis partially-replicated. The object creating site is sd

2. It distributes a constructor


call message to the other two sites. Before distributing the constructor call message,the site sd

2 determined the data holders: itself as the object creating site and thesite s3. Thus, the site s1 executes the default constructor d.c0 and s3 the developer-selected constructor d.c1. Then both sites send an execution confirmation to theobject creating site sd

2. It collects these confirmations and after it received one fromboth sites, it sends a registration permission to these sites. Finally, all sites registerthe new data object and inform the local object-listeners.

7.2 Object Duplication

A common paradigm for working with editors is copy and paste. DreamObjects sup-ports a developer in realizing this paradigm in collaborative applications. Imagine,e.g., a collaborative diagram editor in which every diagram element is representedby a shared data object. If a user selects, copies, and pastes a diagram element, anew data object has to be created that is identical to the previous one apart fromits position. This is not difficult in a single-user application, but in a collaborativeapplication some precautions have to be taken to ensure that every participatingsite creates an identical copy of the shared data object and displays the content ofthe new data object.

DreamObjects offers a service that allows a developer to duplicate shared dataobjects. A developer has to implement a method that creates and returns a cloneof a shared data object, when it is called. Let clone ∈ Md denote this method.This method does not modify the content of d, but as it creates a duplicate of d,it modifies the set of data objects D and thus is a modifying method. A developermust not

• include this method in the specification of modifying methods,

• include this method in considerations concerning concurrency control, and

• call this method directly.

Instead he has to call a special duplication method of the runtime system thattransparently handles the distributed action that duplicates a shared data object.The distributed action uses the developer-defined clone method and automaticallyhandles the concurrency control during the duplication of a shared data object. Itis divided into six phases:

1. Initialization

2. Pre-concurrency control


4. Call-execution

5. Post-concurrency control

7.2. OBJECT DUPLICATION 71

6. Post-execution

Compared to the distributed action for a shared data object registration, theconcurrency control phase is split up into a pre- and post-concurrency control phase.This is necessary, as the modifying action involves a registered object that must notbe modified during its duplication.


To duplicate a shared data object d ∈ D in DreamObjects, a developer just has tocall a duplication method that is offered by the runtime environment. This methodhandles the distributed action for the duplication of a data object d ∈ D and finallyreturns the duplicate d′ ∈ D. A developer has to pass the object that he wantsto duplicate to the method. As with the registration of a shared data object, adeveloper additionally can provide a registration name for the duplicate, but he canalso leave it to the runtime system to generate a registration name.

When a developer calls the duplication method, this method starts the initial-ization phase of the distributed action. When the developer specifies named′ on hisown, the duplicating site, denoted by sd.clone, first checks, if named′ is being usedalready. If it is not being used, sd.clone uses the developer-specified name to createa reference for the new object, otherwise the runtime system reports an exception.The reference refd′ is almost identical to refd. Both only differ in the registrationname named′ and the creating site sd.clone.

After creating the reference, the duplicating site sd.clone creates a duplication callmessage. Table 7.4 shows the content of this message. Besides the timestamp, itincludes the reference of the duplicate refd′ and the reference of the object that isduplicated refd.

tsd.clone The timestamp of the duplication call message, i.e. a time-stamp of sd.clone.

refd The reference of the duplicated object.

refd′ The reference of the duplicate.

Table 7.4: Duplication call message

Pre-concurrency Control Phase

After creating the reference, the runtime system locks the object. This is done ac-cording to the concurrency control scheme the shared data object uses. If the objectuses the object-based concurrency control scheme, the runtime system requests thefloor fd that is associated with the shared data object d and thus prevents any othersite from modifying the object.

If the object uses the method-based concurrency control scheme, the runtimesystem requests all locks lj ∈ Ld that are associated with a modifying method, i.e.all locks in the set {lj|m ∈ EMj ∧ m ∈ MMd ∧ EMj ∈ OEMd}.



When the object is locked, the duplicating site sd.clone sends the duplication callmessage to all other participating sites. This message requests all other sites toduplicate the object with the reference refd and to register the duplicate with thereference refd′ .


Only the sites that hold the data of the object can duplicate its content. Thus, onlythe sites in DHd execute the clone method. The other sites just execute the defaultconstructor c0 ∈ Cd to create an empty instance. So the duplicate d′ gets the samedata holders as d. However, every site duplicates the configuration of d, i.e. theconcurrency control scheme and the evaluator, and assigns this configuration to theduplicate d′.

Imagine, e.g., a video file in a collaborative video cutting application that usesan asymmetric distribution scheme. With the help of DreamObjects duplicationmechanism the video is only duplicated at the data holding site and thus the videodoes not have to be transmitted over the network.

Post-concurrency Control Phase

The distributed action for an object registration uses a two-phased protocol to avoidruntime failures. For the same reasons, DreamObjects uses a two-phased protocolto handle the duplication of a shared data object.

After duplicating the object, all sites in S\{sd.clone} send an execution confirma-tion message to the duplicating site sd.clone. This message contains the timestamptsd.clone, which allows sd.clone to identify the object duplication for which it receivedthe execution confirmation.

When sd.clone received a confirmation from every site, it sends a registrationpermission to all other sites and releases the requested locks. The registration per-mission contains refd′ . The reference allows the receiving sites to identify the objectthat now can be registered.


This phase is similar to the post-execution phase of an object registration. Thesite sd.clone registers the duplicate d′. All other sites wait until they receive theregistration permission or a message that is directed to the duplicate d′. Then theyalso register the duplicate. They store d′ in the local object registry, inform possibleobject-listeners about the new data object, and if necessary, update the sets CLm

with m ∈ MMd′ .

Example

Fig. 7.4 exemplarily shows the duplication of a shared data object d, when DHd ={sd.clone

2 , s3} and d uses the object-based concurrency control scheme, i.e. only one

7.3. OBJECT DEREGISTRATION 73

lock has to be requested.

t t t

��

d.c 0

DC: Duplication call message


LG: Lock grant message

LR: Lock request message


LG

LR

d.clone

LR

DC

EC EC

RP RP

DC d.clone

1 s clone . d

2 s 3

s

Figure 7.4: Example for an object duplication, for DHd = {sd.clone2 , s3}

The site sd.clone2 initiates the duplication of the shared object d. First, it requests

the floor fd for the object. After the site sd.clone2 received the necessary floor, it

distributes the duplication call message. The site s1 is not a data holder of d andthus executes the default constructor d.c0 to create an empty instance. The sites3 is a data holder of d and thus executes d.clone. After either executing the de-fault constructor or the duplication call, these sites send an execution confirmationto sd.clone

2 . The site sd.clone2 collects these confirmations. When sd.clone

2 received aconfirmation from every participating site, it releases the floor fd and distributesa registration permission for the new data object d′. The site sd.clone

2 does not dis-tribute any lock release messages, as DreamObjects by default uses TCP/IP and thetoken-based lock according to Singhal (see section 6.3.1), which does not use releasemessages. However, all sites finally register the duplicate d′ and inform possibleobject-listeners. Additionally, the site sd.clone

2 returns the duplicate d′ as result tothe invoking process.

7.3 Object Deregistration

Apart from registering and duplicating a shared data object, a developer can removea shared data object. For instance, consider the CVE as described in section 2.2.1.A user can remove single elements in the CVE via their context menu. Each pieceof furniture, e.g. a table, a lamp, or a wardrobe, is represented by a shared dataobject. Whenever a user removes a piece of furniture, this changes the state of an


application. Thus, the other sites must be informed. Additionally, DreamObjectsoffers a persistency service (see chapter 9) that allows a user to store and loadcomplete session states, i.e. sets of data objects D. If a developer could not removea shared data object from the set D, a stored session state would contain unnecessarydata objects.

For these reasons, DreamObjects offers a service that allows a developer to dereg-ister a shared data object. This service does not implement a distributed garbagecollection [PS95]. It simply informs the other participating sites about the dereg-istration and removes the respective shared data object from the object registry.After a shared data object was deregistered, the runtime system does not longerknow this object. When, e.g., the application or another object still references thederegistered object and calls a method of this object, the runtime system cannotexecute the method call and instead reports an exception. Thus, a developer has tobe careful and aware of the distributed context and be sure that the deregisteredobject is not referenced by another object.

One might say that the runtime system should check, if the data object that isderegistered is referenced by another object. For this purpose, the runtime systemhad to make a distributed snapshot and suspend all distributed actions, as alreadyone distributed action can add an object to another shared data object and thuschange the snapshot. This would block a user in his current work, whenever a shareddata object is deregistered. This is not desirable.

Therefore, DreamObjects leaves it to the developer to ensure that an object isnot in use anymore. For this reason and as the deregistration does not use anydeveloper-defined methods, the distributed action for the deregistration of a shareddata object is divided into the phases:

1. Initialization


3. Call-execution


To deregister a shared data object d ∈ D in DreamObjects, a developer has just tocall a deregistration method that is offered by the runtime system. Let sd.deregister ∈S denote the site that deregisters a shared data object d ∈ D. The runtime systemat this site uses the initialization phase to create a deregistration call message. Table7.5 shows the content of such a message. It just contains a timestamp of sd.deregister

and the reference refd.

tsd.deregister The timestamp of the message, i.e. a timestamp of the sitesd.deregister.

refd The reference of the deregistered object.

Table 7.5: Deregistration call message

7.4. FLAT METHOD CALLS 75


In this phase the site sd.deregister distributes the deregistration call message to allother sites in S to inform them about the deregistration of the specified data object.


The call-distribution phase ensures that every participating site receives a deregis-tration call message. When a site receives such a message, it determines the shareddata object with the specified reference refd and removes it from its local object reg-istry. If the shared object d is still in use, this can lead to side-effects. As discussedabove, DreamObjects requires that developers are sure that the deregistered objectis not in use anymore. Finally, every site s ∈ S informs the local object-listeners.

7.4 Flat Method Calls

The well-known Remote Procedure Call (RPC) protocol [BN84] offers a solution forthe remote invocation of methods, but does not consider replication. Cooper [Coo85]introduced a protocol for the replicated invocation of a method, but does not consideradaptive distribution schemes. This section describes how DreamObjects handlesflat modifying and reading method calls for all supported distribution schemes.

At runtime DreamObjects replaces developer-defined data objects with theircorresponding substitute (see chapter 4). The mechanisms for both kinds of methodcalls are completely hidden in the substitute of a shared data object. Developers donot have to care about how the other participating sites in a collaborative sessionare involved. As a developer uses the substitute like a local object, DreamObjectsachieves a maximum of transparency.

Each distributed action is divided in seven phases:

1. Initialization

2. Pre-concurrency control


4. Call-execution

5. Result-distribution

6. Post-concurrency control

7. Post-execution

The additional result-distribution phase is necessary, as not every site may holdthe data of an object and thus is able to locally produce the result of a methodcall. Even, when a developer did not define a result for a method, the result-distribution phase is necessary, as a method call may produce an exception that hasto be distributed.


The initialization phase is used to initialize necessary data structures for themethod call. In the pre-concurrency control phase, actions according to the selectedconcurrency control scheme are executed, i.e. the runtime system calls the preMethodmethod of the selected concurrency control scheme (see section 6.3). A method callmessage is distributed in the call-distribution phase and the method call is executedin the call-execution phase. In the result-distribution phase, one site distributes themethod call result. Finally, in the post-concurrency control phase, the postMethod

method of the selected concurrency control scheme is executed and in the post-execution phase the call-listeners are informed.

7.4.1 Flat Modifying Method Call

Whenever a user modifies a shared data object by calling a modifying method,DreamObjects distributes a method call message to keep the shared data objectconsistent. Instead of simply distributing the method call message to all partici-pating sites, DreamObjects just sends the method call message to selected sites,the data holders and the sites that registered call-listeners [Luk02], thus reducingnetwork traffic and the response time.


At the method call initiating site sd.m, the initialization phase for a modifyingmethod call is started by a local event. In this phase, the site sd.m creates a methodcall message. At every other site, this phase is started by a method call messagereceipt.

Table 7.6 shows the content of a method call message. It contains a timestamptsd.m, the reference for the shared data object refd, an identifier idm for the methodm ∈ Md, and the method call arguments Ad.m. While local objects in the methodcall arguments Ad.m are included in the message, the method calling site sd.m replacesany shared data objects in Ad.m with their reference. When a site receives a methodcall message, it exchanges the references with the corresponding local shared dataobject. This ensures that each site applies possible changes to the respective localinstance of the shared data objects in Ad.m.

tsd.m The timestamp of the method call message, i.e. a timestamp of sd.m.

refd The reference of the object.

idm The unique identifier for the method m ∈ Md.

Ad.m The method call arguments.

Table 7.6: Method call message


The pre-concurrency control phase is used for ensuring the consistency of the shareddata object. The necessary steps depend on the concurrency control scheme the


developer chose and configured for the shared data object:

1. If the object uses the object-based concurrency control scheme, the runtimesystem at the method call initiating site sd.m just checks, if it owns the neces-sary floor fd. In this case, the next phase is executed. Otherwise the runtimesystem reports an exception.

2. If the object uses the method-based concurrency control scheme, the methodcall initiating site sd.m requests all locks in MLd.m. When all locks were granted,the next phase is executed.


In the call-distribution phase, the method call initiating site sd.m determines therecipients of the method call message and distributes the message. To keep theshared data object consistent, all sites in DHd have to be informed about the methodcall. Additionally, the message has to be distributed to all sites, which are not dataholders of d, but registered call-listeners for the data object.

Chapter 5 described that a developer can register call-listeners for methods inMMd. Let CLs

m denote the set of call-listeners at a site s ∈ S. As CLsm can vary

from site to site, the runtime system of every site maintains a set SCLm ⊆ S thatcontains the sites si ∈ S for which CLsi

m contains at least one call-listener.To keep SCLm up-to-date, the runtime system of a site s ∈ S distributes call-

listener add messages as well as call-listener remove messages to every participatingsite. Whenever a developer registers a call-listener that traces the changes of aparticular data object, the runtime system checks, whether it has to distribute acall-listener add message. If the call-listener is the first local call-listener of a methodm ∈ MMd, the runtime system distributes a call-listener add message as shown intable 7.7. Otherwise, the other sites already know that s listens to m ∈ MMd andthus s does not have to distribute a call-listener add message.

ts The timestamp of this message, i.e. a timestamp of the sitethat adds a call-listener.

refd The reference of the object.

idm The unique identifier for the method m ∈ MMd.

Table 7.7: Call-listener add message for a particular data object

When s deregisters all call-listeners for a method m ∈ MMd and after this|CLs

m| = 0, it distributes a call-listener remove message to all other participatingsites. This message has the same structure as the call-listener add message.

The runtime system of a site s ∈ S also has to inform other sites, when a de-veloper registers or deregisters a call-listener that traces data objects of a particularclass. Again, s distributes a call-listener add message, when the registered call-listener is the first one that observes one method or all modifying methods of aparticular class of data objects. Table 7.8 shows the content of the corresponding


call-listener add message that contains the name of the data class nameclassd. When

the call-listener uses the mapping-based notification service, it further contains theidentifier idm for the method m ∈ MMd. When the call-listener uses the event-basednotification service, it contains a value the indicates that the call-listener listens toall modifying methods.

ts The timestamp of this message, i.e. a timestamp of the sitethat adds a call-listener.

nameclassdThe name of the class for the specific data type.

idm The unique identifier for the method m ∈ MMd.

Table 7.8: Call-listener add message for a type of data objects

If a developer deregisters a call-listener that traces the changes of data objectsof a particular class, the runtime system checks, if this call-listener was the lastcall-listener for this class. In this case, it distributes a call-listener remove mes-sage. This message has the same structure as the corresponding call-listener addmessage. Thereby, DreamObjects ensures that all sites can update their local setsSCLm correctly, whenever a new data object of the specified class is registered.

The set SCLm allows the site sd.m to reduce the number of recipients for themethod call message. Instead of simply distributing the method call message to allparticipating sites and thus causing unnecessary network traffic sd.m distributes themessage to all sites in

DHd ∪ SCLm.

The sites in DHd receive the method call message to keep the object consistent, thesites in SCLm to inform local call-listeners.


In the execution-phase, each site in DHd executes the method call. All other sitesthat received the method call message, enter into a wait state, until they receivethe result. As already argued, every method call can lead to an exception andthus a result. Therefore, a site s 6∈ DHd cannot skip the call-execution and result-distribution phase.

Result-distribution Phase

DreamObjects assumes that the developer configured the concurrency control suchthat every data holding site executes all conflicting, modifying methods under mu-tual exclusion. This guarantees that sites in DHd produce the same result for themethod call d.m. This constraint is also being used in the state machine [Sch90] oractive replication [WPS+00] approach.

The state machine approach is based on the assumption that different copies ofa shared data object produce the same result when they are provided with the sameinput in the same order. In the state machine approach, all sites that executed themethod call send the result to the method calling site sd.m. DreamObjects uses a


different approach that reduces the network traffic. As all sites produce the sameresult rd.m, only one site has to distribute the result. This site is called write master.

The runtime system associates a write master wmd ∈ DHd with every shareddata object. When a shared data object is created, the runtime system selects theobject creating site sd as write master wmd. When an object is duplicated, thewrite master of the duplicated object also becomes the write master of the newobject. DreamObjects only selects a new write master for a shared data object,when the current write master left the session. If the participating sites do notknow each other, the selection of a new write master requires a distributed electionmechanism, as e.g. described in [GM82]. However, as the runtime environment ofDreamTeam ensures that every participating site knows the other participating ones,DreamObjects simply chooses the site sj ∈ DHd with the lowest site identifier idsj

as new write master.The write master distributes a method call result message (see table 7.9) to all

sites in(SCLm ∪ sd.m) \ DHd.

Thus, all waiting sites receive the result and can leave their wait states.

ts The timestamp of this message, i.e. a timestamp of wmd.

rd.m The method call result.

tsd.m The timestamp of the method call.

sized The size of the data object in bytes.

Table 7.9: Method call result message

The result message contains the timestamp tsd.m which allows the receiving sitesto determine the distributed action that waits for the result and it contains themethod call result. Before distributing the result message, the write master wmd

checks, if the result rd.m contains some shared data objects and replaces them withtheir references. A site that receives a result message exchanges the references withthe corresponding local shared data object. This ensures that the result receivingsite uses the respective local instances of the shared data objects that are containedin rd.m. Only a data holding site can determine the size of a shared data object.The size of a shared data object is one of the values that influence the adaptivedistribution of a shared data object (see section 11.2). For this reason, the size isincluded in the result message.

As already argued, any site in DHd could distribute a method call result. Ifthe current write master has to distribute the result and leaves the session beforedistributing the result, the new write master takes on the result distribution. Forthis purpose, each site in DHd \ {wmd} started a thread that may take on thedistribution of the result. If the current write master wmd does not fail, it sendsa confirmation message (see table 7.10) to all other data holders to inform themabout the result distribution. The confirmation message contains the timestamptsd.m. This timestamp enables the receiving sites to determine and stop the threadthat was started for possibly taking on the result distribution.


ts The timestamp of this message, i.e. a timestamp of wmd.

tsd.m The timestamp of the method call.

Table 7.10: Method call result sent confirmation message


Based on the concurrency control scheme used by d ∈ D, different actions areperformed. If the shared object d uses the object-based concurrency control scheme,nothing has to be done.

In case of the method-based concurrency control scheme, it must be ensured thatall sites executed the method call d.m, before a method is executed that conflicts withd.m. For this purpose, each site in DHd\{s

d.m, wmd} sends an execution confirmationmessage to the method call initiating site sd.m, if the lock set MLd.m 6= ∅. Theconfirmation message has the same structure as the execution confirmation messagefor an object registration (see table 7.2).

Normally, the write master wmd does not send an execution confirmation, asit confirmed the execution by distributing the method call result. However, if theshared object d uses a replicated distribution scheme, it is not necessary to distributethe result and the write master wmd sends an execution confirmation.

The method call initiating site sd.m collects these confirmations in a thread differ-ent to the one that executes the method call. If sd.m ∈ DHd, the site locally notifiesthis thread. The thread releases the requested locks, as soon as every site that hadto send a confirmation message either sent one or left the session. Thereby, no sitecan request a lock in MLd.m, until all sites executed the method call d.m.


Finally, each site s ∈ (DHd ∪{sd.m}∪SCLm) informs the call-listeners in CLsm about

the executed method call d.m.

Example

Fig. 7.5 shows an example for a modifying flat method call. In this figure three sitesparticipate in a collaborative session. At each site a box indicates the executiontime of the distributed action for a method call d.m. Again, a hatched box indicatesthat the respective site is not a data holder. Thus, the local substitute for d onlyhandles the distributed action for the method call d.m and does not really executethe method.

The site sd.m1 calls the method m ∈ MMd of the partially-replicated object d ∈ D.

As the shared object d uses the method-based concurrency control scheme, thesite sd.m

1 first requests the necessary locks. The site s2 grants the necessary locks.After this, the site sd.m

1 determines the recipients of the method call message. AsDHd = {s2, s3}, the site sd.m

1 distributes the method call message to the both othersites. In the call-execution phase, the sites in DHd execute the method call, while sd.m

1

waits for the method call result. The site s2 distributes the result, as this site is the


t t t

d.m

LG

d.m

EC

EC: Execution confirmation message LG: Lock grant message

LR: Lock request message MC: Method call message MCR: Method call result message RSC: Result sent confirmation message

MC

MCR RSC

LR

��

d.m

m . d 1 s

2 s 3 s

Figure 7.5: Example for a modifying method call, for m ∈ MMd, SCLm ={sd.m

1 , s2, s3}, DHd = {s2, s3}, and wmd = s2

write master wmd. It also sends a confirmation message to the site s3, which informss3 about the result distribution. In the post-execution phase each site informs thelocal call-listeners. With the receipt of the execution confirmation from the sites3, the method call initiating site sd.m

1 knows that every participating site executedthe method call and releases the requested locks. Remember that DreamObjectsby default uses TCP/IP and the token-based lock according to Singhal (see section6.3.1). Therefore, sd.m

1 does not distribute any lock release messages.

7.4.2 Reading Method Call

To reduce network traffic DreamObjects handles a reading method call differentlyto a modifying one. As a reading method call does not modify a shared data object,just one data holding site has to execute the reading method call and to provide themethod calling site with the result. If the method calling site is a data holding site,it is not necessary to involve other sites at all.


Again, a local event starts the initialization phase at site sd.m, and sd.m createsa method call message. This message has the same structure as the one for amodifying method call: it contains a unique number for the method, the methodcall arguments, the reference of the shared data object, and a timestamp.



Site sd.m executes the actions according to the concurrency control scheme of theshared data object. As the method call does not modify the content of the object,no actions are performed, if the object-based concurrency control scheme is beingused. In case of the method-based concurrency control scheme, sd.m requests alllocks contained in MLd.m.


The call-distribution phase of a reading method call differs from the phase of amodifying one. It distinguishes two cases:

1. sd.m ∈ DHd: The method calling site sd.m does not distribute the method callmessage, since it holds the data of the object and the method call does notmodify the object. Thus it can simply execute the method call locally.

2. sd.m 6∈ DHd: The method calling site sd.m sends the method call message toone data holder of the object. It is the task of the evaluator to determinethis data holding site (see chapter 11). If the first selected data holder leavesthe session before returning the result, sd.m sends the method call message toanother data holder.


The method calling site sd.m enters into a wait state, while the data holding sitethat received the method call message executes the reading method call.


If the method calling site sd.m is a data holder, it executed the method call locallyand nothing has to be done. Otherwise, the data holding site that executed themethod call sends a result message to the method calling site. The result messageis constructed in the same way as during a flat modifying method call.


The method calling site sd.m releases the requested locks. When sd.m did not requestany locks, nothing has to be done.


Since the method call did not modify the content of the shared data object, sd.m

does not have to notify any call-listeners and nothing has to be done. Later, thisphase will be extended to support the adaptive distribution schemes (see chapter11).


Example

Fig. 7.6 shows, how the runtime system handles a sample flat reading method calld.m that is initiated by the site sd.m

1 . First, the site sd.m1 requests the necessary lock

that is needed before d.m can be executed. After the site s2 granted the lock, sd.m1

distributes a method call message to the site s3, as the evaluator for d selected thisdata holding site. Before the site s3 can execute the method call it crashes. Theruntime environment of DreamTeam informs the distributed action for d.m and thesite sd.m

1 distributes the method call message to the next data holding site s2. Thisdata holder executes the method call d.m and returns the result to sd.m

1 .

t t t

��

d.m

LG

d.m

LG: Lock grant message LR: Lock request message MC: Method call message MCR: Method call result message

MC

MCR

LR

MC

m . d 1 s

2 s 3 s

Figure 7.6: Example for a reading method call with a site crash, for m ∈ Md,DHd = {s2, s3}

Chapter 8

Nested Distributed Actions

Complex collaborative applications, like the CVE, often use composite data objects.For a developer it is normal to nest method calls, i.e. to call a method of a dataobject from another method. In the CVE, the move method of the table calls themove method of the lamps on top of the table, whenever a user moves a table withlamps on top of it. Since the move method modifies the content of the table, everydata holder must be informed about the method call and has to execute the methodcall to keep the data object consistent. Therefore, every data holder of the table alsoexecutes the move method of the lamps. As this modifies the lamp objects, everydata holder of the table informs all data holders of the lamps and each data holderof a lamp receives and executes the move method as often as there are data holdersfor the table. Obviously, this leads to a lot of unnecessary method call messagesand to an unintended position of the lamps, as the lamps are relatively moved. Justimagine, what would happen, if the move method of the lamps would call anothermodifying method.

As DreamObjects wants to simplify the development of collaborative applica-tions, it has to support nested distributed actions and thereby achieve transparencyfor the developer. A developer has to be allowed to nest method calls. As anotherexample, consider how a developer creates composite data objects. Such objectsare often created in the constructor of the data object that contains them. So,DreamObjects has to support nested object registrations. The same applies to theduplication of shared data objects. When a developer wants to create a copy ofa composite data object, he must be able to duplicate the contained data objectsduring the duplication of the object that contains them. Sometimes it also canbe necessary to nest different distributed actions, e.g. if the result of a modifyingmethod is a new shared object. Similarly, a developer has to be allowed to deregistera shared data object from a method, e.g. when he removes a piece of furniture froma room.

Independent of the kind of nested distributed actions, the problem that a sitereceives several messages for one distributed action has to be solved. Mazouni etal. [MGG95b] consider this as the duplicated invocation problem. They discuss twosolutions:

1. Post-filtering : A site that receives a message for a distributed action checks

85

86 CHAPTER 8. NESTED DISTRIBUTED ACTIONS

whether it has already received a message for the same distributed action ornot. If yes, it simply ignores the additional message. Though this leads to thedesired effect, it still increases the network traffic.

2. Pre-filtering : Only a special, coordinating site distributes a message, if nec-essary. This solution avoids that a site receives several messages for one dis-tributed action.

Example systems that use post-filtering are Circus [Coo86] and Arjuna [LMS93,LS94]. Compared to the post-filtering approach, pre-filtering saves computing re-sources, as only one message is distributed for the distributed action and thus isonly considered once. However, pre-filtering has to take into account that the coor-dinating site fails and the necessary message is not distributed at all. Wood [Woo93]extended the distributed operating system Amoeba [TKvRB91] to support replicatedmethod calls. To avoid duplicated invocations he uses a pre-filtering approach. Ma-zouni [MGG95a] does the same in the distributed object system GARF.

DreamObjects [Luk02] also uses the pre-filtering approach and thus only dis-tributes a message for a distributed action, if necessary. Compared to the pre-filtering approach of Mazouni and Wood, the pre-filtering approach of DreamObjectsdeals with a variety of distribution schemes. Additionally, it also avoids duplicatedinvocations if the coordinating site fails.

Let di.mi ; dj.mj ; dk.mk ; · · · ; dp.mp ; df .mf denote a sequence ofnested method calls, i.e. di.mi calls dj.mj, dj.mj calls dk.mk, and so on. If di.mi wasnot initiated by another method call, it is called initiating. A method call dp.mp

that initiates a further method call df .mf is called previous method call of df .mf ,while df .mf is called follow-up method call of dp.mp.

t

d 2 .m

2

d 1 .m

1

d 3 .m

3

d 4 .m

4

d 6 .m

6

d 5 .m

5

Figure 8.1: Example for nested method calls

87

Fig. 8.1 shows an example for nested method calls. The boxes indicate the timesfor method calls. The arrows between the boxes indicate that the active methodcall changes. For instance, the arrow from the box for d1.m1 to the box for d2.m2

indicates that d1.m1 initiates the method call d2.m2. At the end of the method calld2.m2 the arrow indicates that the method call d2.m2 is finished and a possible resultis returned. The grey boxes exemplarily highlight the sequence of method calls thatleads to the method call d5.m5, i.e. d1.m1 ; d2.m2 ; d4.m4 ; d5.m5. The sequencedoes not contain the method call d3.m3, as its execution is finished. The methodcall d1.m1 is the initiating method call, d4.m4 is the previous method call of d5.m5

and the follow-up method call of d2.m2.Similar to the sequence of method calls, di.ci ; dj.cj ; · · · ; dp.cp ; df .cf

denotes a sequence of object registrations and di.clonei ; dj.clonej ; · · · ;

dp.clonep ; df .clonef a sequence of object duplications. DreamObjects permitsa developer to nest different kinds of distributed actions, e.g. di.mi ; dj.mj ;

· · · ; dp.cp ; df .cf denotes a combination of method calls and object registrations.The following table (see table 8.1) shows which distributed actions can initiate

which distributed actions.

;

Modifyingmethodcall

Readingmethodcall

Objectregistration

Objectduplication

Objectderegistration

Modifyingmethodcall

X X X X X

Readingmethodcall

X

Objectregistration X

Objectduplication X X X X X

Table 8.1: Possible nested distributed actions

A modifying method call and an object duplication can initiate all other dis-tributed actions. Per definition, an object deregistration cannot initiate anotherdistributed action, as it does not involve a developer-defined method or constructor.

A reading method call can just initiate another reading method call. Otherwise,it would initiate a modifying distributed action and thus had to be declared asmodifying. If, e.g., the method call d1.m1 in fig. 8.1 is a modifying method call, i.e.m1 ∈ MMd1

, the method call d4.m4 can either be a modifying or a reading methodcall. If d4.m4 is a reading method call, the method call d5.m5 has to be a readingone, but the method call d6.m6 can be modifying again, as it belongs to a differentsequence.

During an object registration, the constructor of a substitute class first has to callthe developer-defined constructor of the respective data class, before it can initialize


the substitute. This includes, e.g., the concurrency control scheme. A developer canuse the constructor of a data class to set values passed in the constructor argumentsor initiate another object registration. Thereby, a developer easily can implementcomposite data objects. Apart from object registrations, he must not initiate otherdistributed actions, as they require that the substitute is initialized.

The following sections describe the distributed actions for these allowed combina-tions. The distributed actions are divided into the same phases as the correspondingflat distributed actions. However, the initialization and post-execution phase of theinitiating distributed action had to be extended, as a site must be able to recognizeand identify a follow-up distributed action to apply the pre-filtering approach.

In the initialization phase of an initiating distributed action, e.g. a method calldi.mi, each site creates a local method call stack MCSdi.mi

, puts di.mi on this stack,and registers it in the runtime environment using the timestamp tsdi.mi

. Addition-ally, each site creates and registers a follow-up counter fcdi.mi

. The stack and thecounter are deregistered in the post-execution phase of di.mi. Whenever a follow-up distributed action is initiated, this action is put on the stack and the follow-upcounter is incremented. When the execution of a follow-up distributed action isfinished, it is removed from the stack.

The content of the stack represents the current sequence of distributed actions, asthe bottom of the stack contains the initiating call and the top of the stack containsthe call that is currently being executed. The following sections will show that thecontent of the method call stack can vary from site to site because of the differentsupported distribution schemes. As the follow-up counter is not decremented, everyfollow-up distributed action gets a unique number. Together with the timestamptsdi.mi

, a follow-up counter uniquely identifies a follow-up distributed action.To illustrate how the method call stack and the follow-up counter are used,

consider again fig. 8.1. The method call d1.m1 initiates the method call d2.m2,which initiates the method calls d3.m3 and d4.m4. In the initialization phase ofd4.m4, the follow-up counter fcd1.m1

has the value four and the method call stackMCSd1.m1

has the following content: d1.m1, d2.m2, d4.m4.

8.1 Follow-up Modifying Method Call

A follow-up modifying method call can be initiated in the call-execution phase ofeither a previous modifying method call dp.mp or a previous object duplicationdp.clonep. The distributed action for df .mf is in both cases the same. Therefore,the following sections just describe the procedure for a previous modifying methodcall. As the distributed action is handled by the substitute of df , DreamObjectsagain achieves a maximum of transparency.

8.1.1 Initialization Phase

In the initialization phase of a modifying follow-up method call df .mf a site eitherexecutes the previous method call dp.mp or received a method call message for df .mf .Every site that executes the initialization phase puts df .mf on the method call stack

8.1. FOLLOW-UP MODIFYING METHOD CALL 89

MCSdi.miand increments the follow-up counter fcdi.mi

. If a site executes dp.mp, itcreates a method call message for df .mf . Table 8.2 shows the content of a follow-upmethod call message.

tsdf .mfThe timestamp of the follow-up method call message.

refdfThe reference of the follow-up object.

idmfThe unique number for the method mf ∈ Mdf

.

Adf .mfThe method call arguments

refdiThe reference of the initiating object.

idmiThe unique identifier for the method mi ∈ Mdi

.

tsdi.miThe timestamp of the initiating method call.

fcdi.miThe value of the follow-up counter.

refdpThe reference of the previous object.

idmpThe unique identifier for the method mp ∈ Mdp

.

tsdp.mpThe timestamp of the previous method call.

Table 8.2: Follow-up method call message

Since the follow-up counter fcdi.miand the timestamp of the initiating method call

tsdi.miidentify a follow-up method call, both are included in the follow-up method

call message. Due to the different distribution schemes, a site does not necessarilyexecute dp.mp and thus does not know the complete sequence of nested method calls.However, when it receives the method call message for df .mf , it receives informationabout the initiating, previous, and follow-up method call. The following sectionsshow that this information enables every site to update or initialize the method callstack MCSdi.mi

and the follow-up counter fcdi.mi.

8.1.2 Pre-concurrency Control Phase

DreamObjects offers an object-based and method-based concurrency control scheme.Depending on the chosen concurrency control scheme different actions are performed.

Object-based Concurrency Control

If df uses the object-based concurrency control scheme, the runtime system at themethod call initiating site sdi.mi checks if it holds the necessary floor and in this casedistributes a method call start permit message to all sites that are involved in theexecution of df .mf . These sites are

(SCLmf∪ DHdf

∪ DHdp) \ {sdi.mi}.

To be sure that the method call initiating site sdi.mi holds the floor, a site onlyexecutes the method call df .mf , when it receives such a start permit message. Table8.3 shows the content of such a message. The message contains the timestamp of


ts The timestamp of this message, i.e. a timestamp of sdi.mi .



Table 8.3: Method call start permit message

the initiating method call and the value of the follow-up counter. This allows everyreceiving site to associate the message with the correct follow-up method call.

If the method call initiating site sdi.mi does not hold the necessary floor, it abortsthe execution of df .mf and distributes a method call abort message to all sites thatare involved in the execution of df .mf . A site that receives a method call abortmessage, cancels the execution of df .mf and reports an exception. A method callabort message has the same structure as a method call start permit message andthus every receiving site can associate the message with the correct follow-up methodcall.

Method-based Concurrency Control

If the shared object df uses the method-based concurrency control scheme, themethod call initiating site sdi.mi requests all necessary locks for df .mf because ofthe following two reasons:

• The method call initiating site sdi.mi can already hold some of the locks that arenecessary for the execution of the follow-up method call df .mf . This is possiblebecause of the inter-object concurrency control configuration of method callsprior in the sequence than df .mf . If a site different from sdi.mi would requestthe locks, this could lead to a deadlock.

• The method call initiating site sdi.mi has only to request the locks in MLdf .mf

that it does not hold yet. This reduces network traffic.

Even when all necessary locks are requested, inconsistencies can occur. Fig.8.2 shows what could happen without an additional synchronization between theparticipating sites. Site sd1.m1

1 initiates the method call d1.m1 which leads to themethod call d2.m2. Both data objects are replicated, both methods are modifying,and for each method locks have to be requested. The site sd1.m1

1 requests the locksfor m1 and distributes the method call message. Each site starts the execution ofd1.m1 which leads to the method call d2.m2. Sites s2 and s3 start the execution ofd2.m2 even before sd1.m1

1 requested the necessary locks. Thus, site s2 could executea method call that conflicts with m2, before it grants the necessary lock for themethod call d2.m2 to s1.

To avoid this, sdi.mi distributes a method call start permit message to all othersites in DHdf

as soon as all locks in the lock set MLdf .mfwere granted. In the call-

execution phase, all data holding sites check, whether they received the necessarystart permit message or not. If not, they wait until they receive the start permit.Otherwise, they execute the method call.


d 1 .m

1 d

1 .m

1

t t

MC: Method call message MCR : Method call result message LR: Lock request message LG: Lock grant message

LR(m 1 )

LG(m 1 )

LG(m 2 )

t

MC(m 1 )

LR(m 2 )

d 1 .m

1

d 2 .m

2

d 2 .m

2 d

2 .m

2

1 m . 1 d

1 s 2 s 3 s

Figure 8.2: Execution order problem with nested modifying method calls, ford1.m1 ; d2.m2, DHd1

= DHd2= {sd1.m1

1 , s2, s3}

If the intra-object concurrency control configuration of mi does not require torequest any locks, sdi.mi omits the start permit message. As the intra-object con-figuration of a method provides static information, a site has always to request thesame locks before it can execute a method. Every site knows the selected concur-rency control scheme of a shared data object. Thus, each site can easily determine, ifsdi.mi has to request some locks and thus if it has to wait for a start permit messageor not.

8.1.3 Call-distribution Phase

The write master wmdpdistributes the method call message for the follow-up method

call df .mf to the sites

(SCLmf∪ DHdf

∪ {sdi.mi}) \ DHdp.

The method call message is sent to all sites in SCLmfto inform their call-listeners.

It is sent to all sites in DHdf, as these sites have to execute the method call. Fur-

thermore, it is sent to the method call initiating site sdi.mi , as this site may haveto request some locks. Finally, it is not sent to any site in DHdp

, since these sitesalready execute df .mf . Thereby, DreamObjects solves the duplicated invocationproblem for nested modifying method calls and reduces the network traffic. If the


previous object dp, e.g., uses a replicated distribution scheme, the follow-up methodcall message is not distributed at all.

If the current write master wmdphas to distribute the method call message and

leaves the session before distributing the method call message, the new write mastertakes on the method call distribution. For this purpose, each site in DHdp

\ {wmdp}

started a thread that can take on the call distribution. If the current write masterwmdp

does not fail, it sends a confirmation message (see table 8.4) to all otherdata holders to inform them about the successful distribution. When a site in DHdp

receives such a confirmation message, it uses the contained timestamp tsdi.miand

follow-up counter fcdi.mito identify and stop the thread.

ts The timestamp of this message, i.e. a timestamp of wmdp.



Table 8.4: Method call sent confirmation message

8.1.4 Call-execution Phase

All sites in DHdfexecute the follow-up method call. All sites outside of DHdf

whicheither received the method call message for df .mf or are executing the previousmethod call dp.mp enter a new wait state, until they receive the result.

8.1.5 Result-distribution Phase

The write master wmdfdistributes the result of the follow-up method call to all sites

in(SCLmf

∪ DHdp∪ {sdi.mi}) \ DHdf

.

The result is sent to all sites in SCLmfto inform their call-listeners. It is sent

to all sites in DHdp, since they wait for the result. Finally, it is sent to sdi.mi , as

the method call initiating site participates in the distributed action for df .mf . Ofcourse, the result is not sent to any site in DHdf

, since these sites were able toexecute the follow-up method call locally.

ts The timestamp of this message, i.e. a timestamp of wmdf.

rdf .mf The method call result.

sizedfThe size of df in bytes.



Table 8.5: Follow-up method call result message

Table 8.5 shows the content of a follow-up method call result message. Comparedto the result message for a flat method call, it additionally contains the timestamp


of the initiating method call and the value of the follow-up counter, as they uniquelyidentify the follow-up method call.

When the write master wmdfhad to distribute the result, it distributes a result

sent confirmation message (see table 8.6) to all sites in DHdfto inform them about

the successful result distribution. Like in the result-distribution phase of a flatmodifying method call, this permits the other data holders to identify and stop thethread that could have taken on the result distribution.

ts The timestamp of this message, i.e. a timestamp of wmdf.



Table 8.6: Follow-up method call result sent confirmation message

8.1.6 Post-concurrency Control Phase

If df uses the object-based concurrency control scheme, nothing has to be done. Inthe other case, all sites in

DHdf\ {sdi.mi , wmdf

}

send an execution confirmation message to sdi.mi . The message has the same struc-ture as a result sent confirmation message for a follow-up method call (see table 8.6)and thus contains tsdi.mi

and fcdi.mi. Thereby, the site sdi.mi can easily identify the

method call for which it received the confirmation.

Normally, the write master wmdfdoes not send an execution confirmation, as

it confirmed the execution by distributing the method call result. However, if theshared object df uses a replicated distribution scheme, it is not necessary to dis-tribute the result and the write master wmdf

sends an execution confirmation.

At the method call initiating site sdi.mi , a thread different to the execution threadcollects the execution confirmations. If sdi.mi is not a data holder of df , it notifiesthis thread locally. When this thread received all necessary confirmations or thesites that had to sent a confirmation left the session, it releases all requested locks.

If, based on the intra-object concurrency control configuration of the methodcall df .mf , the lock set MLdf .mf

is empty, the data holders omit the confirmationmessage. This is possible, as the intra-object concurrency control configurationprovides static information that is available at every site.

8.1.7 Post-execution Phase

Finally, every site s ∈ S that was involved in the distributed action for the follow-upmethod call df .mf either executed the follow-up method call or received the methodcall result. Each of these sites informs the local call-listeners in CLs

mfand removes

df .mf from the method call stack MCSdi.mi.


8.1.8 Example

Fig. 8.3 shows an example for two modifying method calls, i.e. d1.m1 ; d2.m2. Thesite sd1.m1

1 calls the method m1 of the partially-replicated object d1. The data objectsd1 and d2 use the method-based concurrency control scheme and the methods m1

and m2 just have to be executed self-exclusive. Thus, the site sd1.m1

1 requests thenecessary lock for the method m1 and the site s2 grants this lock. After this, thesite sd1.m1

1 distributes the method call message for d1.m1. As the sites s2 and s3 aredata holder of d1, the site sd1.m1

1 sends the method call message to both sites.

t t t

��

d 2 .m

2

EC: Execution confirmation message LG: Lock grant message LR: Lock request message MC: Method call message

MCR: Method call result message MCSC: Method call sent confirmation message MCSP: Method call start permit message RSC: Result sent confirmation message

MC(m 1 )

��

d 1 .m

1

d 1 .m

1 d

1 .m

1

d 2 .m

2

MC(m 2 ) MCSC(m

2 )

MCR(m 2 )

EC(m 1 )

RSC(m 1 ) MCR(m

1 )

MCSP(m 2 )

LR(m 1 )

LG(m 1 )

LR(m 2 )

LG(m 2 ) � �

� ��

d 2 .m

2

2 s 3 s 1 m . 1 d

1 s

Figure 8.3: Example for nested modifying method calls, for d1.m1 ; d2.m2, m1 ∈MMd1

, m2 ∈ MMd2, DHd1

= {s2, s3}, DHd2= {s3}, wmd1

= s2, wmd2= s3

This leads to the follow-up method call d2.m2. As the site s2 is the write masterwmd1

, it is its task to distribute the method call message for the method call d2.m2.The site s2 sends the method call message to sd1.m1

1 , as sd1.m1

1 may have to requestsome locks for the execution d2.m2. Furthermore, the site s2 sends a confirmation

8.2. FOLLOW-UP READING METHOD CALL 95

message to s3, as s3 could undertake the task to distribute the method call messagefor d2.m2, but now this is not necessary anymore.

Upon method call message receipt, the site sd1.m1

1 checks, if it has to request somelocks for d2.m2. In this example, it has to request a lock. Again, the site s2 grantsthe necessary lock. After the lock was granted, the site sd1.m1

1 sends a start permitmessage to the only data holder of d2.

The site s3 executes the method call d2.m2 and distributes the result to the sitessd1.m1

1 and s2 and informs the local call-listeners. The site sd1.m1

1 uses the resultto inform the local call-listeners. It does not have to wait for any confirmationmessages, as the only data holder sent the result message. Therefore, the site sd1.m1

1

directly releases the requested locks for d2.m2. The site s2 uses the result to informlocal call-listeners and to continue the execution of the method call d1.m1.

After site s2 finished the execution of d1.m1, it sends a result message to sd1.m1

1 ,as sd1.m1

1 initiated the method call and does not hold the data of d1. Site s2 sends aconfirmation message to s3, as s3 could undertake the task to distribute the result,but now this is not necessary anymore.

After site s3 finished the execution of d1.m1, it sends a confirmation messageto sd1.m1

1 . Site sd1.m1

1 collects these confirmation messages and when it received aconfirmation message from every data holder of d1, it releases the requested locksfor d1.m1. Furthermore, every site uses the post-execution phase of d1.m1 to informlocal call-listeners.

8.2 Follow-up Reading Method Call

DreamObjects uses two different mechanisms to handle a follow-up reading methodcall. Again, both mechanisms are completely hidden in the substitutes and thusachieve a maximum of transparency for the developer. The first one is used, ifthe initiating distributed action is a modifying one, the second, if the initiatingdistributed action is a reading method call.

In the first case, DreamObjects could use the same mechanisms as for a follow-up modifying method call. However, as a follow-up reading method call does notchange the content of a shared data object, it is not necessary that every dataholder executes it. In the second case, only the method call initiating site sdi.mi isinterested in the execution of the initiating method call and its follow-up methodcalls. Thus, in both cases it is possible to reduce the number of sites that executethe method call and thereby reduce the network and CPU load of the participatingsites. For this reason, the call-distribution, call-execution, and result-distributionphase of the distributed action for a follow-up modifying method call were modified.The following sections describe these phases.

Additionally, there are some changes to the pre- and post-concurrency controlphases. As the follow-up reading method call does not modify the content of theobject, nothing has to be done, if the object-based concurrency control scheme isused. In case of the method-based concurrency control scheme, only the sites thatexecuted the method call have to send an execution confirmation to the method callinitiating site sdi.mi .


8.2.1 Initiating Modifying Distributed Action

This section assumes that the reading method call df .mf is initiated by the sequencedi.mi ; dj.mj ; · · · ; dp.mp and that mi ∈ MMdi

, but there can also be objectduplications in the sequence.


It is again the task of the write master wmdpto distribute the method call message.

The notification service of DreamObjects only considers modifying method calls.Thus, there are no call-listener sets CLmf

and SCLmfand the write master distributes

the method call message to all sites in

(DHdf∪ {sdi.mi}) \ DHdp

.

When the write master wmdphad to distribute the method call message, it

now distributes a confirmation message to all other sites in DHdp. This is done to

inform the data holders of dp that the method call message for df .mf was distributedsuccessfully and they can stop the thread to take on the method call distribution.


As df .mf does not modify the content of df , only the sites in

(DHdp∩ DHdf

) ∪ {wmdf}

execute the method call. The sites that are a data holder of dp and df execute df .mf ,since they can use the result to continue the execution of dp.mp. The write masterwmdf

executes the method call, as it is again its task to distribute the result.The sites in

DHdf\ (DHdp

∪ {wmdf})

do not execute the method call, as the method call does not modify df and they donot need the result rdf .mf to finish the execution of dp.mp. Instead they enter intoa wait state, which they leave, when wmdf

confirmed the result distribution. If thewrite master wmdf

leaves the session without confirming the result distribution, thenew write master leaves the wait state and takes on the task of the previous writemaster.


The write master wmdfdistributes the result of the method call df .mf . For this

purpose, wmdfdistinguishes two cases:

1. mp ∈ MMdp: The write master wmdf

distributes a method call result messageto the sites in

DHdp\ DHdf

.

It sends the result to all data holders of dp, since they execute dp.mp. It doesnot send the result to any site that holds the data of df , because these sitesexecuted the method call locally. This reduces CPU and network load.

8.2. FOLLOW-UP READING METHOD CALL 97

2. mp 6∈ MMdp: If the write master wmdp

is not a data holder of df , the writemaster wmdf

sends a method call result message to wmdp. Thereby, the write

master wmdpcan finish the execution of dp.mp.

When the write master wmdfhad to distribute the result, it now distributes a

result sent confirmation to all other data holders of df . Upon confirmation reception,they can stop the thread that was started to take on the method call execution andresult distribution.

Example

Fig. 8.4 shows an example for an initial modifying and a follow-up reading methodcall, i.e. d1.m1 ; d2.m2 with m1 ∈ MMd1

and m2 6∈ MMd2.

t t t

��

d 2 .m

2




MCR: Method call result message

MC(m 1 )

��

d 1 .m

1

d 1 .m

1

MC(m 2 )

MCR(m 1 )

d 2 .m

2

MCR(m 2 )

LR(m 1 )

LG(m 1 )

d 1 .m

1

MCR(m 1 )

2 s 3 s 1 m .

1 d

1 s

Figure 8.4: Example for a follow-up reading method call, for d1.m1 ; d2.m2,m1 ∈ MMd1

, m2 6∈ MMd2, DHd1

= {s2}, DHd2= {sd1.m1

1 }, SCLm1= {sd1.m1

1 , s2, s3},wmd1

= s2, wmd2= sd1.m1

1

In the pre-concurrency control phase the site sd1.m1

1 requests the necessary lockfor the method m1. After the site s2 granted the lock, sd1.m1

1 distributes the methodcall message for d1.m1 to the sites s2 and s3, as DHd1

= {s2} and s3 ∈ SCLm1. The

site s3 directly enters into a wait state and waits for the result, while s2 executesd1.m1.

The method call d1.m1 initiates the method call d2.m2. As the site s2 is nota data holder of the data object d2, it cannot determine the result rd2.m2 locally.


Thus, the site s2 has to distribute a method call message to one of the sites inDHd2

= {s1, s3}. As the method call initiating site is the write master wmd2, s2

sends the method call message to sd1.m1

1 .

As the site sd1.m1

1 is the only data holder, it now executes the method call d2.m2

and sends the method call result message to s2. The site s2 uses the result tocontinue the execution of d1.m1.

Eventually, s2 finishes the execution of the method call d1.m1 and distributes themethod call result message to the sites sd1.m1

1 and s2. Both sites use the method callresult to inform the local call-listeners. Additionally, sd1.m1

1 uses the result receiptas a permission to release requested locks.

8.2.2 Initiating Reading Method Call

This section describes the distributed action for a follow-up reading method calldf .mf that was initiated by the sequence di.mi ; dj.mj ; · · · ; dp.mp withmi 6∈ MMdi

. Compared to the previous distributed action, only the method callinitiating site sdi.mi is interested in the execution of df .mf . Therefore, the numberof involved sites can be reduced even more and only one site executes a method callthat is contained in the sequence of reading method calls.


As already mentioned, only one site executes a method call in the sequence of methodcalls di.mi ; dj.mj ; · · · ; dp.mp ; df .mf . Let sdp.mp denote the site that cur-rently executes the previous method call dp.mp. It is the task of sdp.mp to distributethe method call message for df .mf . In any case, sdp.mp sends the method call mes-sage to the method call initiating site sdi.mi , as sdi.mi may have to request some locks.Besides this, the site sdp.mp distributes the method call message for the method calldf .mf as follows:

• sdp.mp ∈ DHdf: In this case, sdp.mp executes the method call locally and the

method call message is only distributed to sdi.mi .

• sdp.mp 6∈ DHdf∧ sdi.mi ∈ DHdf

: In this case, the site sdp.mp only sends amethod call message to sdi.mi . The site sdi.mi initiated the method call andthus is the only site that is interested in the result of di.mi. Therefore, thesite sdi.mi executes the method call df .mf and uses its own resources insteadof the resources of another site.

• sdp.mp , sdi.mi 6∈ DHdf: Neither the site sdp.mp nor the method call initiating

site sdi.mi can execute df .mf . Thus, the method call message must be sentto at least one data holder of df . The site sdp.mp uses the evaluator of df todetermine the data holder that has to execute the method call (see chapter11). If the first selected data holder fails, sdp.mp sends the method call messageto another data holder.

8.3. FOLLOW-UP OBJECT REGISTRATION 99


The call-distribution phase guarantees that at least one data holder of df receivesa method call message for df .mf . If df uses the object-based concurrency controlscheme, this data holder now directly executes the method call. If df uses themethod-based concurrency control scheme and when sdi.mi had to request some locksfor df .mf , this data holder checks, whether it has already received the necessary startpermit message. In this case, it executes df .mf . Otherwise, it waits until it receivesthe necessary start permit message, before it executes the method call.

Due to the call-distribution phase, the method call initiating site sdi.mi possiblyreceived a method call message for df .mf without being a data holder. If this is thecase, sdi.mi simply skips this phase.


Only one data holder executed df .mf . Thus, it is the task of this data holder todistribute the method call result. It sends the method call result message to sdp.mp ,as this is the only site that needs the result to continue the execution of dp.mp.

Example

Fig. 8.5 shows an example for an initial reading and two follow-up reading methodcalls, i.e. d1.m1 ; d2.m2 ; d3.m3 with m1 6∈ MMd1

, m2 6∈ MMd2, and m3 6∈ MMd3

.

The site sd1.m1

1 initiates the method call d1.m1. As pre-concurrency control stepsare not necessary, it distributes the method call message to the only data holdingsite s3. The site s3 starts the execution of the method call d1.m1. During this, themethod call d2.m2 is initiated.

The only data holder of the data object d2 is the site s2. Thus, the site s3 sendsa method call message to the sites s2 and sd1.m1

1 . Upon method call reception, thesite sd1.m1

1 requests the locks in MLd2.m2. The site s3 grants these locks and sd1.m1

1

sends a method call start permit to the site s2.

The site s2 starts the execution of the method call d2.m2. This method callinitiates the method call d3.m3. As DHd3

= {sd1.m1

1 , s3}, the site s2 sends the methodcall message to the method call initiating site sd1.m1

1 . The site sd1.m1

1 executes themethod call d3.m3 and sends the result to the site s2. The site s2 uses the result tofinish the execution of d2.m2 and sends the respective result to the site s3. The sites3 uses the result to finish the execution of d1.m1. As sd1.m1

1 does not need the resultof the method call d2.m2, the site s2 just sends a confirmation message to sd1.m1

1 .Finally, the site s3 sends the result of the method call d1.m1 to sd1.m1

1 .

8.3 Follow-up Object Registration

Follow-up object registrations are necessary to build composite data objects. Fur-thermore, they permit a modifying method of a shared data object to create sharedobjects and, e.g., to return them as the result of the method call. As a follow-up


t t t

d 2 .m

2


LG: Lock grant message LR: Lock request message


MCR: Method call result message

MCSP: Method call start permit message

MC(m 1 )

d 1 .m

1

� ��

d 2 .m

2

MCSP(m 2 )

MC(m 2 )

d 1 .m

1

��

d 3 .m

3

d 3 .m

3 MC(m 3 )

MCR(m 3 )

MCR(m 2 )

MCR(m 1 )

LR(m 2 )

LG(m 2 )

d 2 .m

2

EC(m 2 )

2 s 3 s 1 m .

1 d

1 s

Figure 8.5: Example for nested reading method calls, for d1.m1 ; d2.m2 ; d3.m3,m1 6∈ MMd1

, m2 6∈ MMd2, m3 6∈ MMd3

, DHd1= {s3}, DHd2

= {s2}, DHd3=

{sd1.m1

1 , s3}

object registration df .cf with cf ∈ Cdfmodifies the state of an application, all dis-

tributed actions in the sequence prior to the object registration df .cf have to bemodifying ones, i.e. a modifying method call, an object duplication, or an objectregistration. As an object registration can only initiate another object registration(see table 8.1), all follow-up distributed action have to be object registrations again.The following list shows some possible sequences of distributed actions:

• di.mi ; dj.mj ; · · · ; dp.mp ; df .cf

• di.clonei ; dj.mj ; · · · ; dp.clonep ; df .cf

• di.ci ; dj.cj ; · · · ; dp.cp ; df .cf

Independent from the sequence that initiates the object registration,DreamObjects uses the same mechanisms. However, the following sections assumethat the object registration df .cf is initiated by the first sequence in the above list.The resulting distributed action is again divided into the five phases initialization,call-distribution, call-execution, concurrency control, and post-execution. For the


other cases, simply exchange di.mi with di.clonei or di.ci, and dp.mp with dp.clonep

or dp.cp.


The call-execution phase of the previous method call dp.mp initiates the registrationof a new object df by calling the registration method of the runtime system. At asite that executes the previous method call dp.mp, the registration method

• pushes df .cf on the method call stack MCSdi.mi,

• increments the follow-up counter fcdi.mi,

• creates the reference refdf, the representation repdf

, and a follow-up construc-tor call message (see table 8.7).

tsdf .cfThe timestamp of the follow-up constructor call message, i.e.a timestamp of wmdp

.

repdfThe representation of the new shared data object.

{ids|s ∈ DHdf} The identifiers of the sites that become a data holder of df .


idmiThe unique identifier for the method mi ∈ Mdi

.




idmpThe unique identifier for the method mp ∈ Mdp

.


Table 8.7: Follow-up constructor call message

The message contains the representation repdfand thus the reference refdf

ofthe new object df . If a developer left it to the runtime system to generate namedf

,the runtime system uses a string representation of the timestamp tsdi.mi

and thefollow-up counter fcdi.mi

as the registration name. In the initialization phase, theseare the only values that uniquely identify the distributed action at every site andthus the shared data object. Furthermore, the message contains the identifiers forthe sites that become a data holder of df .

Due to the different distribution schemes, a site does not necessarily executedp.mp and thus does not know the complete sequence of the distributed actions thatinitiate the object registration df .cf . For these sites, the message contains valuesthat identify the initiating and previous distributed action. Like for a follow-upmethod call, these values allow a site to update the method call stack MCSdi.mi

andthe follow-up counter fcdi.mi

and participate in the distributed action for df .cf .



As the method call dp.mp is a modifying one, all sites in DHdpknow about the

registration of df . Therefore, only the sites in

S \ DHdp

have to be informed. It is the task of the write master wmdpto distribute the

constructor call message for df .cf to these sites.If the data object dp is replicated, the write master wmdp

need not distribute theconstructor call message, in all other cases, the write master wmdp

has to distributeit. Then the write master wmdp

also distributes a confirmation message (see table8.8) to all other data holders of the data object dp. This confirmation message hastwo tasks:

1. All other data holders than wmdpstarted a thread to take on the constructor

call distribution, if wmdpfails. The confirmation message informs these sites

that the constructor call was distributed. Therefore, they can stop the thread.

2. With the help of the evaluator for the data object df , the write master wmdp

determined the set of data holders DHdf. The confirmation message informs

the other data holders of dp, whether they become a data holder of the newobject df or not.

ts The timestamp of the message, i.e. a timestamp of wmdp.

{ids|s ∈ DHdf} The identifiers of the sites that become a data holder of df .



Table 8.8: Constructor call sent confirmation message


If a site becomes a data holder of df , it executes the developer-specified constructor.In the other case, a site executes the default constructor which only creates an emptyinstance.

The site sdi.mi initiated the sequence of distributed actions and thus is also theobject creating site sdf . Independent from the distribution scheme of the new object,the object creating site becomes a data holder (see section 7.1). Thus, the site sdi.mi

executes the developer-specified constructor.The write master wmdp

determined the set of data holders for df and thus auto-matically knows, whether it becomes a data holder of df or not. The sites in S\DHdp

use the constructor call message to determine, whether they become a data holderor not. The sites in DHdp

\ {wmdp} wait until they receive the confirmation mes-

sage, before they either execute the developer-specified or the default constructor.However, after executing the respective constructor each site initializes the shareddata object according to the developer-specified configuration.


8.3.4 Concurrency Control Phase

To avoid the same kind of runtime failures that can occur during a flat object reg-istration (see section 7.1), each site in S \ {sdi.mi} sends an execution confirmationmessage to sdi.mi after executing the constructor. The site sdi.mi collects these con-firmations. After it received a confirmation from every site S \ {sdi.mi} or the sitesthat had to sent one left the session, the site sdi.mi distributes a registration permis-sion message to these sites. This message has the same structure as a registrationpermission message for a flat object registration (see table 7.3) and contains thereference refdf

. This reference enables the receiving sites to identify the object thatnow can be registered.


In this phase, the site sdi.mi registers df . A site s ∈ (S \{sdi.mi}) registers df as soonas it receives the necessary registration permission message or, like for a flat objectregistration (see section 7.1), as soon as it receives a message that is directed to thenew object df . For the registration, each site s ∈ S stores the new object df in thelocal object registry, informs possible object-listeners about the new shared object,and if necessary updates the call-listener sets CLs

m and SCLm with m ∈ MMdf.

Finally, each site removes the constructor call message from the method call stackMCSdi.mi

.

Example

Fig. 8.6 shows an example for an initiating modifying method call and a follow-up object registration, i.e. d1.m1 ; d2.c2 or d1.m1 ; d2.c0 with m1 ∈ MMd1

andc0, c2 ∈ Cd2

.

The site sd1.m1

1 executes the method call d1.m1. According to the configuration ofthe method-based concurrency control scheme, the lock set MLd1.m1

for the methodcall is not empty. Thus, the site sd1.m1

1 first requests the necessary locks. After thesite s2 granted the necessary locks, the site sd1.m1

1 distributes a method call messageto the sites s2 and s3, as these are the only data holders of the data object d1.

Both data holders execute the method call d1.m1. This method call initiates theregistration of the data object d2. The site s2 is the write master wmd1

. Therefore,it is its task to determine the set of data holders for the data object d2, here DHd2

={sd1.m1

1 , s3}. Additionally, the site s2 distributes a constructor call message to thesite sd1.m1

1 and a confirmation message to the site s3. When the developer left it tothe runtime environment to generate the registration name for the new object d2,the site s2 takes a string representation of the timestamp tsd1.m1

and the value offcd1.m1

, i.e. in this example one.

After the sites s2 and s3 executed the constructor, they send an execution con-firmation to the site sd1.m1

1 . The site sd1.m1

1 collects these confirmations and when itreceived one from every participating site, it distributes a registration permission.Eventually, all sites register the new object d2, inform local object-listeners, and


t t t

��

d 2 .c

0

CC: Constructor call message CCSC: Constructor call sent confirmation message EC: Execution confirmation message LG: Lock grant message LR: Lock request message

MC: Method call message MCR: Method call result message RP: Registration permission message RSC: Result sent confirmation message

MC(m 1 )

��

d 1 .m

1

d 1 .m

1 d

1 .m

1

d 2 .c

2

CC(d 2 ) CCSC(d

2 )

EC(m 1 )

RSC(m 1 ) MCR(m

1 )

LR(m 1 )

LG(m 1 )

d 2 .c

2

EC(d 2 )

RP(d 2 )

EC(d 2 )

2 s 3 s 1 m . 1 d

1 s

Figure 8.6: Example for a follow-up object registration example, for d1.m1 ; d2.c2

or d1.m1 ; d2.c0, DHd1= {s2, s3}, DHd2

= {sd1.m1

1 , s3}, wmd1= s2

update the call-listener sets. The rest of the distributed action for d1.m1 is handledin the same way as during a normal method call.

8.4 Follow-up Object Duplication

This section describes the distributed action that is used to handle a follow-upobject duplication. Follow-up object duplications are particularly needed, whena developer wants to create a duplicate of a composite data object. However,a follow-up object duplication can also be initiated by a modifying method call.In both cases, the distributed action is divided into the six phases of a flat ob-ject duplication, i.e. initialization, pre-concurrency control, call-distribution, call-execution, post-concurrency control, and post-execution. This section assumes thatthe follow-up object duplication df .clonef is initiated by the following sequence:

8.4. FOLLOW-UP OBJECT DUPLICATION 105

di.clonei ; dj.clonej ; · · · ; dp.clonep ; · · · df .clonef . For the other case, simplyexchange di.clonei with di.mi and dp.clonep with dp.mp.


All sites in DHdpexecute dp.clonep. At these sites, the call-execution phase of

dp.clonep initiates the duplication of df by calling the duplication method of theruntime environment. The duplication method of the runtime environment handlesthe mechanisms to duplicate the shared data object df . During the duplicationmethod, the data holders of df execute the developer-defined method clonef ∈ Mdf

to create a duplicate. The other sites execute the default constructor c0 ∈ Cdfto

create an empty instance.At the sites that execute dp.clonep, the duplication method of the runtime system

• pushes df .clonef on the method call stack MCSdi.clonei,

• increments the follow-up counter fcdi.clonei,

• creates the reference refd′f, the representation repd′

f, and a follow-up duplica-

tion call message (see table 8.9).

tsdf .clonefThe timestamp of the follow-up duplication call message, i.e.a timestamp of wmdp

.

refd′f

The reference of the new object.


tsdi.cloneiThe timestamp of the initiating duplication call.

fcdi.cloneiThe value of the follow-up counter.



Table 8.9: Follow-up duplication call message

The message contains the reference refd′f

of the new object d′

f . In the reference,

the site sdi.clonei is set as the object creating site, as this site initiated the duplicationthat led to the duplication of df . If the developer left it to the runtime system togenerate named′

f, the runtime system uses a string representation of the timestamp

tsdi.cloneiand the follow-up counter fcdi.clonei

as the registration name. As these valuesuniquely identify the distributed action, they also uniquely identify the shared dataobject.

The message also contains information about the initiating and previous dupli-cation call. The call-distribution phase ensures that a site that does not executedp.clonep receives a duplication call message. These sites use the information that isprovided in the message to start the duplication method of the runtime system andto update the method call stack MCSdi.clonei

and the follow-up counter fcdi.clonei.


8.4.2 Pre-concurrency Control Phase

As the site sdi.clonei can already hold some locks that are necessary to duplicatedf , it is its task to handle the pre-concurrency control phase. Depending on theconcurrency control scheme of df , the site sdi.clonei locks the object differently, i.e. iteither requests the floor fdf

or all locks lj ∈ Ldfthat are associated with a modifying

method, i.e. all locks in the set {lj|m ∈ EMj ∧ m ∈ MMdf∧ EMj ∈ OEMdf

}.When sdi.clonei received the floor or all necessary locks were granted, it distributes

a start permit message to all sites in DHdf. The start permit message contains

tsdi.cloneiand fcdi.clonei

. This enables the receiving sites to identify the correct objectduplication. To ensure that every site creates an identical duplicate d′

f , the sites inDHdf

wait in the call-execution phase until they receive the start permit.


The write master wmdpsends the duplication call message to all sites in S \ DHdp

,as these sites have to be informed about the duplication. If the write master wmdp

has to distribute the call message, it also sends a confirmation message to all sitesin DHdp

\ {wmdp}. The confirmation message has the same structure as one for a

follow-up modifying method call. This message allows a receiving site to stop thethread that was started to take on the call-distribution, if the write master wmdp

fails.


When the sites in DHdfreceived the start permit message, they execute the method

call df .clonef . Otherwise they wait, until they receive the start permit. The sitesthat do not hold the data of df execute the default constructor to create an emptyinstance. Independent from this, every site duplicates the configuration of the dataobject df and assigns it to the duplicate d′

f .

8.4.5 Post-concurrency Control Phase

All sites in S\{sdi.clonei} send an execution confirmation to sdi.clonei . The site sdi.clonei

collects these confirmations. When it received one from every participating site orthe sites that did not send a confirmation left the session, the site sdi.clonei distributesa registration permission (see table 7.3) to all other sites and releases the requestedlocks.


In this phase, the site sdi.clonei registers the duplicate d′

f . All other sites wait untilthey receive the necessary registration permission or any other message that is di-rected to d′

f . Then they also register the duplicate d′

f . For the registration of theduplicate, each site s ∈ S stores the duplicate d′

f in the local object registry, informslocal object-listeners, and, if necessary, updates the call-listener sets CLs

m and SCLm

8.4. FOLLOW-UP OBJECT DUPLICATION 107

with m ∈ MMd′f. Furthermore, each site removes df .clonef from the method call

stack MCSdi.clonei. At the sites in DHdp

, the duplicate d′

f is returned and thus thesites can carry on the execution of the method call dp.clonep.

8.4.7 Example

Fig. 8.7 shows an example for nested object duplications. The duplication of theobject d1 that uses an adaptive distribution scheme leads to the duplication of d2

that uses an asymmetric distribution scheme.

t t t

� ��

d 2 .c

0

DC: Duplication call message

DCSC: Duplication call sent confirmation message EC: Execution confirmation message




DC(d 1 )

d 1 .clone

1

� ��

d 1 .c

0 d

1 .clone

1

d 2 .clone

2

EC(d 1 )

LR(d 1 )

LG(d 1 )

��

d 2 .c

0

EC(d 2 )

RP(d 2 ')

EC(d 2 )

LR(d 2 )

LG(d 2 )

DCSP(d 2 )

EC(d 1 )

RP(d 1 ')

2 s 3 s 1 clone .

1 d

1 s

DC(d 2 )

DCSC(d 2 )

Figure 8.7: Example for nested object duplications, for d1.clone1 ; d2.clone2,d1.c0 ; d2.clone2, or d1.c0 ; d2.c0, DHd1

= {sd1.clone1

1 , s3}, DHd2= {s3}, wmd1

= s3

According to the distribution schemes of the shared data objects, four sequencesof distributed actions are possible:


1. d1.clone1 ; d2.clone2

2. d1.clone1 ; d2.c0

3. d1.c0 ; d2.clone2

4. d1.c0 ; d2.c0

It depends on the set of data holders which sequence a site executes. In theexample, the sites sd1.clone1

1 and s3 are the data holder of the data object d1 and thesite s3 is the only data holder of the data object d2. Thus, the example shows thesequences d1.clone1 ; d2.c0, d1.c0 ; d2.c0, and d1.clone1 ; d2.clone2.

The site sd1.clone1

1 initiates the duplication of d1. After locking the object, thesite sd1.clone1

1 sends a duplication call message to the other sites. The sites sd1.clone1

1

and s3 execute the method call d1.clone1, as they are data holders of d1. The sites2 executes the default constructor d1.c0 to create an empty instance.

The duplication call d1.clone1 initiates the duplication of d2. As the site s3 isthe write master wmd1

, it distributes the duplication call message to the site s2 anda confirmation to the site sd1.clone1

1 . The site sd1.clone1

1 , as the initiator of the nestedobject duplications, locks the object d2 and sends a start permit message to the sites3. After s3 executed the method call d2.clone2 and the site s2 executed the defaultconstructor d2.c0, they send an execution confirmation to sd1.clone1

1 . The site sd1.clone1

1

collects them and sends a registration permission to the sites s2 and s3. After this,all sites register the duplicate d′

2, inform local object-listeners, and update the localcall-listener sets. Furthermore, the sites sd1.clone1

1 and s3 use the duplicate d′

2 to finishthe duplication of d1.

8.5 Follow-up Object Deregistration

This section describes the distributed action that is used to handle a follow-up objectderegistration. The distributed action for the deregistration can be initiated by amodifying method call or an object duplication. Both cases are handled in the sameway. Let di.mi ; dj.mj ; · · · ; dp.mp ; df .deregisterf denote the sequenceof distributed actions that eventually initiate the deregistration of the shared dataobject df . Like during the distributed action for a flat object deregistration, threephases are executed.


All sites in DHdpexecute the previous method call dp.mp. At these sites, the call-

execution phase of the method call dp.mp initiates the deregistration of the dataobject df by calling the deregistration method of the runtime environment. At thesites that execute the method call dp.mp, the deregistration method of the runtimesystem

• pushes df .deregisterf on the method call stack MCSdi.mi,

8.5. FOLLOW-UP OBJECT DEREGISTRATION 109

• increments the follow-up counter fcdi.mi, and

• creates a follow-up deregistration call message (see table 8.10).

tsdf .deregisterfThe timestamp of the follow-up deregistration call message,i.e. a timestamp of wmdp

.

refdfThe reference of the object that is deregistered.






Table 8.10: Follow-up deregistration call message

The main content of the message is the reference refdf, as this allows every

site that receives such a message to determine the object that is deregistered. Thefurther information enables a site that does not execute dp.mp to update or createthe method call stack MCSdi.mi

and the follow-up counter fcdi.mi.


The write master wmdpsends the deregistration call message to all sites in S \DHdp

,as these sites have to be informed about the deregistration. If the write master wmdp

has to distribute the call message, it also sends a confirmation message to all sitesin DHdp

\ {wmdp}. This message allows the receiving sites to stop the thread that

was started to take on the call-distribution, if the write master wmdpfails.


In this phase, all sites deregister the shared data object df , i.e. they remove df fromthe local object registry. Then all sites s ∈ S inform the local object-listeners andremove the deregistration call message from the method call stack MCSdi.mi

.

Chapter 9

Data Persistency

As already argued in section 2.2.5, some groups may require several sessions toaccomplish their goals, may not be able to schedule a common time for synchronouscollaboration, or may not be able to cooperate for a long time. Thus, users must beable to

• store states to resume the collaborative work later and

• prepare data for later use in a session.

For this reason, some groupware platforms, e.g. CBE [LPJW96, PSL99], COAST[SKSH96, SSS99], and TeamRooms [RG96b, RG97b, GR98], use the room metaphorto support a transition between synchronous and asynchronous work. The membersof a group can enter so-called rooms to start collaboration. These rooms are persis-tently stored on a well-known server.

DreamTeam is based on the session metaphor and thus concentrates on syn-chronous collaboration. However, it allows a user to start a groupware applicationin a so-called private mode (see section 2.1), where the application acts as a single-user application. DreamObjects offers a persistency service to support asynchronouscollaboration in DreamTeam. Compared to the room metaphor, the persistency ser-vice works fully decentralized and thus even supports groups that cannot maintainor afford a well-known server.

The persistency service supports a developer as well as a user. A developer canuse the persistency service to store and load shared data objects. A user can accessthe persistency service via the front-end and use it to store, load, and distributesession states. Summing up, the following scenarios are possible:

• A developer can implement application functions that permit a user to loadand store the state of an application. Before a collaborative session starts, auser can start an application or all applications that are used in the session intheir private mode and prepare data for the later session.

• Before a collaborative session finishes, a user can store the session state. Laterhe can load the stored session state and either continue or review his work.

111

112 CHAPTER 9. DATA PERSISTENCY

• The last remaining participant in a collaborative session stores the currentstate. Before he disconnects from the network, he distributes the stored sessionstate to all or only some former participants of the session. When he decidesto resume his work, he first checks, whether a former participant resumedthe session and in this case he simply joins the session. Otherwise he checks,whether he received a newer session state than the stored one and in this caseuses the received session state to resume the session. If none of the previouscases occur, he uses the stored one to resume the session.

The following sections describe the persistency service of DreamObjects.

9.1 Shared Data Objects

At a first glance, it does not seem very difficult to store and load a single shareddata object. However, since DreamObjects supports composite data objects and avariety of distribution schemes, the following problems have to be solved:

• A site s 6∈ DHd wants to store a shared data object d ∈ D. How does the sitereceive the state of the shared data object and possibly contained shared dataobjects? How is consistency ensured?

• A site loads a shared data object, which can be a composite object, to introduceit into a collaborative session. How are the other sites informed about thenewly introduced shared data object?

DreamObjects offers two additional distributed actions to solve these questions,i.e. one for storing shared data objects and one for loading shared data objects. Thesedistributed actions can only be used with shared data objects that are defined aspersistent (see section 7.1). They must not be nested with other distributed actions,as they access site-specific resources, i.e. the local filesystem. For instance, considera modifying method call d.m with d ∈ D that initiates the loading of a shared dataobject from a local filesystem. The method call d.m is executed by each data holderof d. Thus, each site in DHd initiates the loading of the shared data object from itsown local filesystem which of course fails.

9.1.1 Storage

A developer has to call a special method of the runtime system to store a shareddata object d ∈ D. The arguments of this method are

• the shared data object d and

• a file, to which the runtime system has to write d.

First, this method checks, if the shared data object d is defined as persistent.In this case, the method proceeds. Otherwise, the method directly returns an errormessage.

9.1. SHARED DATA OBJECTS 113

To store a shared data object, a site has to be a data holder of d and all containedshared data objects. Let sd.store ∈ S denote the site that wants to store the objectd ∈ D. To become a data holder of all objects that d contains, sd.store first has todetermine these objects. Let Id ⊆ D denote the set of shared data objects that d

contains.

Depending on the current distribution of a shared data object d ∈ D, i.e. the setof data holders DHd, a site s ∈ S may not be able to determine Id. For instance,consider three shared data objects d1, d2, and d3. The shared data object d1 containsd2 and the shared data object d2 contains d3, i.e. Id1

= {d2, d3} and Id2= {d3}. The

site s1 ∈ (DHd1∩ DHd2

) can determine the set Id1locally, as it is a data holder of

the data object d1 and d2. Now, consider the site s2 with s2 ∈ DHd1and s2 6∈ DHd2

.The site s2 can only determine that the data object d1 contains the data object d2.As it does not hold the data of d2, it cannot determine whether the data object d2

contains the data object d3. Thus, the site s2 can only determine a subset of Id1.

Let Isd ⊆ Id denote the subset of Id that can be determined by a site s ∈ S.

The example shows that Isd.store

d can just be a subset of Id. So, the site sd.store firsthas to determine Id and request the state of all shared data objects in Id. For thispurpose, sd.store uses the algorithm in fig. 9.1. In principal, the algorithm performsa depth-first traversal of the shared objects contained in d and requests the state ofall data objects in Id. The algorithm either finishes, when sd.store is a data holder ofd and of all shared data objects in Id, or, when d or any object in Id is not definedas persistent.

1 request_inner_objects(d)

2 if d not checked and d persistent then

3 if sd.store 6∈ DHd then

4 request state for d

5 end if

6 mark d as checked

7 ∀ di ∈ Isd.store

d : request_inner_objects(di)

8 else if d is not persistent

9 abort and return error message

10 end if

Figure 9.1: Inner object request

To request the state of a shared object, the algorithm uses a protocol that is alsoused for adaptive distribution schemes (see section 11.2.3). This protocol transfersthe state of a shared object d from a data holding site to a site that wants to becomea data holder. Therefore, it does not transfer the state of the objects in Id, as thesite just wants to become a data holder of d and not its contained shared objects.

When the algorithm successfully finishes, the site sd.store

• locally suspends every method call in its initialization phase that is directedto d or any shared data object in Id and


• waits until all method calls finish that currently are executed and directed tothese shared data objects.

Then the site sd.store writes the data object d and its contained objects to thedeveloper-defined file.

9.1.2 Loading

This section describes how a shared data object is loaded and distributed to theother participants in the session. If a developer wants to load a shared data object,he has to call a special method of the runtime system. As arguments, he has tospecify

• the application that loads the shared data object

• and the file from which the runtime system has to load the shared data object.

The application is specified by its application reference refapp. An applicationreference refapp is part of every object reference refd. When DreamObjects storesa shared data object d ∈ D, it also stores its reference refd and representationrepd. The runtime system needs the representation to initialize the shared dataobject, when it is loaded. The reference is necessary to identify the shared dataobject. However, a shared data object need not be loaded by the same applicationthat stored it. DreamObjects uses the specified application reference to replace thestored application reference.

When a site loads a shared data object, e.g. to introduce prepared data to thesession, this changes the state of the session and the other sites must be informedabout this change. The mechanism that is used to inform the other sites about theloaded object is quite similar to the one for a flat object registration. It is divided intothe five phases, initialization, call-distribution, call-execution, concurrency control,and post-execution.


Let sd.load ∈ S denote the site that loads the shared data object d ∈ D. In this phasesd.load creates a load call message. Table 9.1 shows the content of this message. Itcontains a timestamp of sd.load, the reference refd and thus the developer-specifiedapplication reference refapp. Thereby, every receiving site can identify the registeringapplication. The message also contains byted, a byte representation of the shareddata object d and its contained objects, as it was read from the developer-definedfile. Finally, the load call message contains for each loaded object, i.e. {d} ∪ Id, atuple that contains its reference and the identifiers of the sites that become a dataholder of it. The site sd.load determined these site identifiers with the help of theevaluator.


In this phase the site sd.load distributes the load call message to all other sites in S.

9.1. SHARED DATA OBJECTS 115

tsd.load The timestamp of this message, i.e. atimestamp of sd.load.

refd The reference of the loaded object.

byted The byte representation of d ∈ D.

{(refdi, {ids|s ∈ DHdi

})|di ∈ ({d} ∪ Id)} For each loaded shared data object atuple that contains its reference and theidentifiers of the sites that become adata holder of it.

Table 9.1: Load call message


When a site receives a load call message, it uses the contained byte representationbyted to load the shared data object d and the data objects in Id. During thisoperation, a site replaces a shared data object for which it does not become a dataholder with an empty instance by using the default constructor.

Concurrency Control Phase

In this phase, all sites send an execution confirmation message (see table 7.2) tothe site sd.load. When sd.load received such a message from every site or the sitesthat did not send a confirmation left the session, sd.load distributes one registrationpermission message for d to all other sites in S (see table 7.3). This is done for thesame reasons as during a flat object registration (see section 7.1). It is not necessaryto distribute a registration permission message for every data object in Id, as theregistration permission for d includes the registration permission for the data objectsin Id.


The site sd.load registers the data object d and all objects in Id. All other sites waituntil they either receive the registration permission for the data object d or any othermessage that is directed to d or any of the objects in Id (see section 7.1). Then theyalso register the data object d and all objects in Id. Finally, each site s ∈ S informsthe local object-listeners and updates the call-listener sets.

Example

Fig. 9.2 shows a sample load call distribution. The site sd.load2 loads the shared data

object d and distributes a load call message to the sites s1 and s3. These sites use thereceived message to load the shared data object d. After loading d, the sites s1 ands3 send a confirmation message to sd.load

2 . The site sd.load2 collects these confirmations

and when it received one from every site, it sends a registration permission to thesesites.


t t t

LC

RP

EC EC

RP

LC: Load call message EC: Execution confirmation message RP: Registration permission message

LC

load . d 2 s

3 s 1 s

Figure 9.2: Example for a load call

9.2 Session State

The persistency service of DreamObjects extends the session concept of DreamTeamto support asynchronous collaboration. Users can store session states to preserveachieved results. They can load a session state to review the results or to resumetheir work. Finally, they can distribute a session state to other users. A user thatreceives a session state can import it and use it to resume the session. Services tohandle session states are completely integrated into the front-end of DreamTeam.This front-end extension allows users to simply manage local as well as receivedsession states.

9.2.1 Storage

Every user in a session can store the state of a session by initiating the storageprocess via the front-end. In a dialog window (see fig. 9.3) the user can either entera new name for the session state or overwrite an already existing state for that kindof session. Furthermore, the user can enter a comment for the session state.

When the user entered the necessary information, DreamObjects stores thesession state with the user-defined name and comment in a local database.DreamObjects also stores the corresponding session profile of DreamTeam. Thestored session profile allows DreamObjects to associate a stored state with a sessionprofile that is managed by the session manager of DreamTeam. As a user can changethe session profile in the session list of DreamTeam, e.g. by including or removingapplications, it can become incompatible to the stored session state. In this case,DreamObjects uses the stored session profile to resume the session. Finally, a usercan distribute a session state to another user, whose runtime system does not knowthe corresponding session profile. Nevertheless, the user can use the session state asit contains the corresponding session profile.

Let Dper ⊆ D denote the set of persistent data objects. If a site s ∈ S wants tostore the session state and is a data holder of all objects in Dper, it stores one dataobject d ∈ Dper after another. If the data object d contains shared data objects that

9.2. SESSION STATE 117

Figure 9.3: Session state storage dialog

are not defined as persistent, the site s replaces them with a null value, as it doesnot contain any state specific information. Before storing d, the site s again

• locally suspends every method call in its initialization phase that is directedto d or any shared data object in Is

d and

• waits until all method calls finish that currently are executed and directed tothese objects.

If the site s is not the data holder of all objects in Dper, it first determines theobjects for which it is not a data holder and uses the protocol (see section 11.2.3)that is also used for adaptive distribution schemes to request the state of theseobjects.

9.2.2 Loading

A dialog window allows a user to manage all session states that are locally available.Fig. 9.4 shows a sample screenshot of the DreamTeam front-end. The upper leftcorner shows the main window of the DreamTeam front-end. The lower left cornershows the session window that allows a user to start, stop, and join sessions. Via thesession window, a user can open the dialog window for the session state management.The upper right corner shows this window. The window is divided into two parts.The left part lists the session profiles for which session states are available. The rightpart lists the available session states for the selected session profile. After selecting asession state, a user can view the stored information about the session state, load thesession state, send the session state to another user, change the stored informationabout the session state, or delete the session state. The lower right window showsa sample information dialog that displays the name of a session state, its storagedate, the name of the user who stored the state, and the user-defined comment.

When a user at a site s ∈ S decides to load a session state, DreamObjectsfirst extracts the contained session profile and checks, if the local session list already


Figure 9.4: Session state info dialog

contains a session profile with the same identifier. In this case, DreamObjects furtherchecks, if the session profile in the session list is compatible to the stored one, i.e.it contains the same application list, and if the local user is its originator, i.e. he isallowed to start the session (see section 2.1). In this case, nothing has to be done.Otherwise, DreamObjects adds the stored session profile to the session list and setsthe local user as the originator of the added session profile. This ensures that thesession list contains a session profile that is compatible to the stored state, and thatthe local user is permitted to start the session.

After this, DreamObjects extracts the stored data objects from the session state,adds all contained data objects to the local object registry, and starts the applica-tions that are defined in the session profile. The applications can request the loadedshared objects and so resume the stored session state. After the applications werestarted, the session manager of DreamTeam automatically informs all other userswho are currently online about the started session. These users can join the sessionand also resume the collaborative work.

9.2.3 Distribution

DreamObjects offers a service to distribute session states and to import sessionstates. Thereby, DreamObjects supports a transition between synchronous andasynchronous collaboration.

Imagine a collaborating group in which one user after another leaves the session.Finally, there is only one user left in the session. Since this user knows that he is thelast one and the users agreed on resuming the session the next day, this user storesthe session state. This user knows that he cannot attend the session on the next day.Therefore, the group either needs a well-known server that can be accessed by atleast the last user and the user that wants to resume the session on the next day or

9.2. SESSION STATE 119

the group needs another service that makes the session state available for resuming.The persistency service of DreamObjects does not rely on a well-known server,

but still makes the session state available to the members of the group. In accordanceto the long-term rendezvous of DreamTeam [RU99], DreamObjects uses the SimpleMail Transfer Protocol (SMTP) [Pos82] and the Network News Transfer Protocol(NNTP) [KL86]. It includes the session state in a message that is distributed viaSMTP or NNTP. The necessary mechanisms to convert the session state and toattach it to a message are carried out by DreamObjects. A user need not exportthe session state and to distribute it with his own mailing application.

A user, e.g. the last member of a collaborating group, can asynchronously dis-tribute a session state to other users. Via SMTP, the distributing user can exactlydefine the recipients of the session state, e.g. according to an agreement during thesynchronous collaboration. The distribution via NNTP can be compared with stor-ing the session state on a well-known server. However, it is not necessary to maintainan additional server, as an existing resource is reused.

Figure 9.5: Session state send dialog

The distribution service is accessed via a dialog window that is integrated in thefront-end. Fig. 9.5 shows a sample screenshot of this dialog window. A user canspecify

• the subject and text of the message,

• the recipients of the message, and


• the newshost and newsgroup to which the message is posted.

In addition to the distribution service, DreamObjects offers an import service. Auser can configure, if the import service scans a newsgroup or his incoming mailbox.Furthermore, he can configure how often the import service scans for new sessionstates, e.g. whenever the runtime environment is started or every ten minutes. Hecan also explicitly start the import service. If the import service finds a new sessionstate, it imports it to the local session state database and informs the local userabout the imported session state. Then the user can decide, whether he loads andthus resumes the session or not.

Chapter 10

Latecomer Support

Users can join or leave a collaborative session. A user who joins a session, called late-comer, needs the current shared state to participate in the session. DreamObjectssupports two mechanisms that allow a latecomer to join a session and provide thelatecomer with the current state. The first mechanism directly transfers the currentstate of a session to the latecomer. A latecomer should use the direct state transferto join an active session, if he is not interested in how the current state was reached.The second mechanism replays the distributed actions that led to the current stateand so provides the latecomer with a consistent state. However, to participate in thesession and all distributed actions, a latecomer needs more than a consistent stateof all shared data objects. Particularly, a latecomer needs

• the set of shared objects D, the set of data holders DHd, and the write masterwmd for each data object d ∈ D,

• the set of sites SCLm for each modifying method m ∈ MMd of a shared objectd ∈ D that contains the sites that registered a call-listener for the modifyingmethod,

• the information which sites registered call-listeners for data objects of a par-ticular class.

Prakash et al. [PSL99] postulate that a latecomer support has to be fault-tolerant,e.g. the site that supports a latecomer can leave the session, and must not block thecurrent participants of the session in their work. The direct state transfer as well asthe join with a replay fulfill these requirements. Additionally, both mechanisms

• work completely decentralized, i.e. there is no well-known site that supportsall latecomers,

• are completely integrated in the runtime environment, and

• relieve a developer from supplying the latecomer with a consistent state.

The following section describes some platforms that support a direct state trans-fer. It illustrates the problems that a decentralized latecomer support has to solve.Then it shows how DreamObjects solves the problems for a direct state transfer.The rest of the chapter handles the replay mechanism.

121

122 CHAPTER 10. LATECOMER SUPPORT

10.1 Direct State Transfer

Most of the existing groupware platforms only offer a rudimentary latecomer supportor even leave it to the developer to implement the necessary mechanisms. However,there are some platforms that relieve a developer from this task and use the directstate transfer to accommodate a latecomer.

The Collaboratory Builder’s Environment (CBE) [PSL99] uses a communicationinfrastructure that is based on a central Corona Server [HMJ+96, SHPJ97, SP98].This server handles the group communication, keeps a copy of the shared state,and logs all messages that are sent between the participants. Because of this, it isquite simple for the server to provide the latecomer with a snapshot of the currentstate. The latecomer support is independent from client failures, but depends onthe availability of the central server.

The Real-Time Application Level Protocol for Distributed Interactive Media(RTP/I) [Mau00a, Mau00b, MHKE01] is an application level protocol that is de-rived from the Real-Time Transport Protocol (RTP) [SCFJ96]. While RTP focusseson the transmission of audio and video data, RTP/I is used by collaborative appli-cations and deals with distributed interactive media. It associates a state with thedistributive interactive media that is partitioned into subcomponents. The state isreplicated to every participating site and can be changed by events. RTP/I offerssome generic services, like, e.g., a consistency service [VM01] and a generic late-join service [VMG+00]. The late-join service defines different late-join policies, e.g.event-triggered late-join, immediate late-join, etc. These policies can be assigned tothe different subcomponents. Based on the defined policies, the subcomponents aretransferred to the latecomer. It is the task of the consistency service to ensure thatthe latecomer gets a consistent state of the subcomponents. The consistency ser-vice is based on the Timewarp algorithm [Edw97] that uses optimistic serialization.RTP/I uses physical timestamps to define the necessary total order of the events.For this reason, RTP/I requires that the participating sites synchronize their physi-cal clocks, e.g. with the help of GPS receivers or the Network Time Protocol (NTP)[Mil92].

DreamTeam also offers a latecomer support [Rot00b] that uses a direct statetransfer. Instead of a central server, it is the task of the session originator to supplya latecomer with the actual state of the session. This is done without blocking theother users in their current work. However, when the session originator leaves thecurrent session, it is not possible for a latecomer to join the session.

CBE, RTP/I, and DreamTeam only consider a single distribution scheme. In theCBE as well as in DreamTeam, a well-known site coordinates the latecomer support.If this site is unavailable, a latecomer cannot join the session. RTP/I demands thatthe physical clocks of the participating sites are synchronized. Normally, this cannotbe assumed, as this requires that a participating site is either equipped with specialhardware or can use NTP. Compared to these approaches, the latecomer supportof DreamObjects handles a variety of distribution schemes. For fault-tolerance,it works completely decentralized. Additionally, it does not require any specialhardware.

10.1. DIRECT STATE TRANSFER 123

A first, naive approach for the direct state transfer is to let the latecomer’s siteselect a participating site to provide it with the current state of the session. Thenext three examples show what can happen, if this approach is used.

t t t

CON: Connecting message MC: Method call message REQ: State request message SUP: State supporting message

d .m

d .m

SUP

REQ

CON

MC d .m

m . d 1 s

2 s 3 s

Figure 10.1: A latecomer’s site receives a consistent state

Fig. 10.1 exemplarily shows, how site s2 supports the latecomer’s site s3 witha consistent session state. First, the site s3 connects to all sites. Then it requeststhe session state from site s2. Site s2 receives the request message and sends s3 thesession state. After site s3 received the session state, site s1 executes a modifyingmethod call. As the sites s2 and s3 have a consistent session state, they can partici-pate in the execution of the method call d.m and keep the local state consistent.

t t t


d .m

d .m

MC

SUP

REQ

CON

m . d 1 s

2 s 3 s

Figure 10.2: A latecomer’s site does not receive a modifying message

Fig. 10.2 shows that this naive approach does not guarantee a consistent state forthe latecomer. Again, site s3 joins the session and selects the site s2 as the supporting


site. Site s1 executed a method call d.m before it received the connecting message ofthe latecomer. Thus, it did not distribute the method call message to the latecomer.Due to network latencies, the supporting site s2 receives the corresponding methodcall message, after it sent the session state to the latecomer. Thereby, the latecomerhas an outdated state.

A requirement for the latecomer support is not to block the already participat-ing sites. Thus, these sites can modify the session state while a site supports thelatecomer. Fig. 10.3 shows what can happen, when a site executes a modifyingmethod call, after the latecomer’s site sent a connecting message. Again, the site s3

joins the session and selects the site s2 as the supporting site. The site s1 executesthe method call d.m and sends a method call message to the sites s2 and s3. Thelatecomer buffers the message as it does not yet have the session state. The site s2

executes the method call before it sends the session state to the site s3. Thereby, thelatecomer receives a session state in which the method call d.m is already included.If the latecomer’s site also executes the method call d.m, its session state can becomeinconsistent.

t t t


d .m

REQ

SUP

CON

d .m

Buffer

d .m

MC

m . d 1 s

2 s 3 s

Figure 10.3: A latecomer’s site receives a modifying message twice

Zander [Zan01] developed a latecomer support for DreamObjects that addressesthe above problems. She split the latecomer support in three phases, a connection,an initial, and a final one. In the connection phase, the latecomer’s site establishesits connections to the other participating sites. From this point of time, the othersites partly include the latecomer’s site in the message exchange during the differentdistributed actions. In the initial phase, the latecomer’s site requests an initial statefrom an arbitrary site. As the other sites continue their work and possibly changethe state, this initial state can be outdated. For this reason, the latecomer’s siteuses a final phase to balance the received state with the other participating sites.DreamObjects still uses these phases, though they had to be adapted to support newfeatures of DreamObjects, e.g. adaptive distribution schemes or nested distributedactions.


10.1.1 Connection Phase

If a user wants to join a session, he has simply to select it in the session windowof DreamTeam (see fig. 10.4) and to decide if he wants to join with a direct statetransfer or with a replay (see section 10.2). Then the connection phase is started.

Figure 10.4: A user joins an active session

In the connection phase, the session manager of DreamTeam (see section 2.1)updates the set S at every participating site, i.e. the latecomer’s site slc is added tothe set S. After this, slc initializes the network connections to all other sites in S.When slc connects to a site s ∈ S, it sends a timestamp to this site. Furthermore,it informs the site that it wishes to join the session with a direct state transfer. Thereceiving site stores this timestamp as the connection timestamp of the latecomertsslc→s and returns a timestamp. The latecomer stores this as the connection time-stamp tss→slc

. Later slc uses the stored timestamps to determine, whether its sessionstate is outdated or not.

Remember that the participating sites are not blocked during the latecomersupport and can modify the session state, while the latecomer’s site slc joins thesession. As it is not clear for which methods slc will register a call-listener or towhich sets DHd it will belong, each site partly includes the latecomer’s site in themessage exchange for the different distributed actions. Thereby, the latecomer’ssite slc receives a method call message and method call result message for everymethod call that is either modifying or was initiated by a modifying distributedaction. Additionally, it receives an object registration, object duplication, and objectderegistration message, whenever a shared data object is registered, duplicated, orderegistered.

When the latecomer’s site slc finally joins the session, it informs all other sites.Then slc just receives the messages as specified by the distributed actions. Untilthen, slc adds all above messages to a message buffer MBslc .

10.1.2 Initial Phase

After the latecomer’s site slc connected to all sites, it selects a site ssup ∈ S as theinitial supporter that supplies it with the initial state. For this purpose, it uses


the connection type that each participating site has to specify in DreamTeam. Theconnection type varies between a slow modem connection and a fast, direct connec-tion to the Internet. The latecomer’s site slc determines the sites that specified thefastest connection type and then measures the round-trip time of a simple message.The site with the lowest round-trip time is selected as the initial supporter ssup. Torequest the state from ssup, the latecomer’s site slc sends an initial support requestmessage to ssup.

DreamObjects does not transfer the complete session state at once. Instead, ittransfers the state on a per-object basis. If the first selected supporter leaves thesession before its latecomer support finishes, the latecomer’s site can select a newinitial supporter which can resume the latecomer support instead of starting a newlatecomer support.

Let Dsup denote the set of objects that have to be transmitted to slc and let Dlc

denote the objects that have already been transmitted to the latecomer’s site slc.When the initial supporter ssup receives a request message, it sets Dsup = D andDlc = ∅. Then the initial supporter ssup determines the shared data objects d ∈ Dsup

with ssup 6∈ DHd and for which the respective evaluator decides that slc does notbecome a data holder. For each of these objects, ssup sends an initial representationsupport message to slc, adds d to Dlc, and removes it from the set Dsup. Table10.1 shows the content of such a message. Apart from a timestamp, the messagecontains the representation repd. As slc does not become a data holder of d, therepresentation contains the information that slc needs to create an empty instanceof d ∈ D. When the latecomer’s site slc receives a representation support message,it directly creates the empty instance and adds it to the local object registry.

ts The timestamp of the message, i.e. a timestamp of ssup.

repd The representation of d ∈ D.

Table 10.1: Initial representation support message

Fig. 10.3 showed the situation where a latecomer’s site executes a method call,though it has already been applied to the received state. To solve this problemand later to allow a join with a replay, every site maintains a history list. In thepost-execution phase of every modifying distributed action, i.e. a modifying methodcall, an object registration, an object duplication, an object loading or an objectderegistration, every site that participated in the execution of the distributed actionadds the corresponding message to its history list. When a site loads a session state(see section 9.2.2), it creates a load call message for every loaded object and adds itto the history. Thereby, the history list can be used to determine already executed,modifying distributed actions.

The history list uses the timestamp of the message as a sorting criteria. As notevery site participates in the session from its beginning or executes every modifyingmethod call, the content of the history list can vary from site to site. Let H denotethe complete history list of a session and Hs ⊆ H denote the history list at a site s.Furthermore, let Hd ⊆ H denote the subset of the complete history list that containsall messages that were directed to the data object d ∈ D and let Hs

d ⊆ Hd denote


the subset of messages that is known to the site s ∈ S. Finally, let TSH denote thetimestamps of the messages in the history list H.

There is a further enhancement to ensure that a follow-up distributed action,e.g. a modifying method call df .mf , can be identified by the timestamp of its corre-sponding message. In the initialization phase of a follow-up method call df .mf , eachdata holder of the previous data object dp creates a method call message for df .mf .In the call-distribution phase of df .mf , only the write master wmdp

distributes themessage to all sites that have to be informed. The sites in DHdp

\ {wmdp} do not

receive a method call message from the write master wmdp. Instead, the write mas-

ter wmdpsends a confirmation message to these sites. This message informs them

about the successful message distribution. Thus, the sites in DHdp\ {wmdp

} wouldadd a message with a different timestamp to the local history list as the sites thatreceived a message from wmdp

. To prevent this, the write master wmdpincludes

the timestamp tsdf .mfof the follow-up method call message in the respective con-

firmation message. The sites that receive this confirmation message exchange theirlocal timestamp with the one from the confirmation message, before they add themessage for the distributed action to the local history list.

After the initial supporter ssup sent the initial representation support messages,it supplies the latecomer’s site slc with the remaining data objects in Dsup. Forthis purpose, the site ssup sends for each of the remaining objects an initial objectsupport message to the latecomer’s site slc. Table 10.2 shows the content of sucha message. When the site ssup transfers the data object d to the latecomer’s siteslc, it automatically transfers all objects that d contains to slc, i.e. I

ssup

d . The dataobject d can contain some of the data objects that have already been transferred tothe latecomer. To avoid that a data object is transferred twice and to reduce thenetwork load, the site ssup replaces all objects in I

ssup

d ∩Dlc with their references. Toinform slc about the distributed actions that were directed to any of these objectsand were executed, the object support message contains the timestamps of thesedistributed actions.

ts The timestamp of the message, i.e. a time-stamp of ssup.

d The shared data object.

{TSHssupdi

|di ∈ ({d} ∪ (Issup

d \ Dlc))} The timestamps of the modifying dis-tributed actions that were directed to anyof the contained objects.

Table 10.2: Initial object support message

The initial supporter ssup currently may execute method calls that are directedto the shared data object or shared data objects it contains. To ensure that thetransferred data objects are in a consistent state and the message contains thetimestamps of all distributed actions, the initial supporter ssup

• locally suspends every method call that is directed to any shared data objectin {d} ∪ (I

ssup

d \ Dlc), and


• waits until all method calls finish that currently are executed and directed to{d} ∪ (I

ssup

d \ Dlc),

before the object support message is sent to the latecomer’s site slc. After themessage was sent, the site ssup removes the transferred objects from Dsup and addsthem to Dlc.

When the latecomer’s site slc receives an object support message, it

• replaces possible shared data object references for the objects in Dlc with theircorresponding local instances,

• adds each other shared data object, i.e. {d} ∪ (Issup

d \ Dlc), to the local objectregistry, and

• stores the received timestamps in its local history list Hslc .

The initial supporter ssup transfers the session state on a per-object basis. If theinitial supporter leaves the session before its latecomer support finishes, another sitecan resume the latecomer support. For this reason, the latecomer’s site slc selectsa new initial supporter as soon as it notices that the current one disconnected andsends an initial support resume message to the new initial supporter. Table 10.3shows the content of such a message. When the new initial supporter receives sucha message, it starts the initial support almost as if it was the first initial supporter.The only difference is that it sets Dsup to D \ Dlc and thus does not start from thebeginning. Finally, when Dsup is empty, the supporting site ssup sends a message toslc that indicates the end of the initial phase.

ts The timestamp of the message, i.e. a timestamp of slc.

{refd|d ∈ Dlc} The references of the shared data objects that slc has alreadyreceived.

Table 10.3: Initial support resume message

10.1.3 Final Phase

After the initial phase is finished, the latecomer’s site has an initial session state.The initial state can be outdated, as the other participating sites continued theirwork and possibly changed the session state. When a site changed the session state,after it connected with the latecomer’s site, the latecomer’s site received and bufferedthe corresponding message. However, fig. 10.2 showed what can happen, when a sitechanged the session state, before it connected to the latecomer’s site. In this case,the latecomer’s site is not informed about the modification and the initial state maynot contain this modification. The following approaches avoid this:

1. The supporting site can supply the latecomer’s site with all messages that itreceives after it connected with the latecomer’s site. However, as the support-ing site never knows, when to stop forwarding the messages, the latecomer


does not really join the session. Additionally, the latecomer’s site can receivesome messages twice, which unnecessarily increases the network load.

2. Each site to which the latecomer’s site connects sends the connection time-stamp via the supporting site to the latecomer’s site. If the connecting net-work delivers messages in order, this ensures that the supporting site receivedand applied all messages sent by a site before the latecomer’s site initializedits connections. This approach is used in DreamTeam [Rot00b]. However, inthis case one central site manages the latecomer support and it is not possibleto resume it, when the central site fails.

3. The latecomer’s site can ask every participating site, if there are some messagesleft that it did not receive, but has to receive. If there are such messages, thesite supplies the latecomer’s site with them. Thereby, the latecomer’s site getsall the information it needs to balance the initial state.

DreamObjects uses the last approach, as it ensures that the latecomer definitelyjoins a session and does not rely on a central site. As soon as the latecomer’s siteslc receives the message that indicates the end of the initial phase, it distributes afinal state request message (see table 10.4) to all other sites. Besides a timestampof the latecomer’s site slc, this message contains the connection timestamps thatthe latecomer’s site stored during the connection phase. The message contains thetimestamps of the distributed actions that were executed before the latecomer ini-tialized its connections. Furthermore, the message contains two sets of references,one containing the references of the shared data objects for which the latecomer isa data holder and the other containing the references for which the latecomer is nota data holder.

ts The timestamp of the message, i.e. a timestampof slc.

{tss→slc|s ∈ S} The set of connection timestamps.

{ts|ts ∈ TSHslc ∧ ts.id = ids

∧ts < tss→slcfor all s ∈ S}

The timestamps of the messages in Hslc with atimestamp that is less than the corresponding con-nection timestamp.

{refd|slc ∈ DHd} The references of the shared data objects for whichslc is a data holder.

{refd|slc 6∈ DHd} The references of the shared data objects for whichslc is not a data holder.

Table 10.4: Final state request message

Each site that receives such a message is called final supporter. Let ssup ∈ S

denote such a site. When a final supporter ssup receives a final state request message,it adds slc to the sets DHd as specified by the message. Then it checks, if its localhistory list contains any messages that the latecomer did not receive by now, butneeds to balance the initial state.


Due to the connection phase, the latecomer’s site slc received all necessary mes-sages from a site s ∈ S with a timestamp ts > tss→slc

. Therefore, a final staterequest message must only contain the timestamps in Hslc that are less than thecorresponding connection timestamps. Thereby, the size of the message is reduced.This also implies that a final supporter ssup only has to check the messages in itslocal history list Hssup with a timestamp ts < tss→slc

. Such a message must beforwarded to the latecomer’s site, when it fulfills the following requirements:

1. The timestamp of the message is not in the set of timestamps that is specifiedin the final state request message. If the timestamp of the message is in theset, the initial state already contains the corresponding distributed action.

2. The message is directed to a shared data object of which the latecomer is adata holder or may become a data holder, when balancing the initial state.Thus, a message must be forwarded, if it is not directed to a shared data objectas specified by the set {refd|slc 6∈ DHd}.

Let Hsup ⊆ Hssup denote the subset of the local history that a final supporterssup must forward to the latecomer’s site slc. After ssup determined Hsup, it sends afinal state support message to slc. Table 10.5 shows the content of such a message.Of course, the message contains the subset Hsup of the local history. Remember thatslc needs more than a consistent state of the shared data objects in D to participatein the session. For this reason, each final supporter ssup includes the correspondinglocal information in its final state support message.

ts The timestamp of the message, i.e. a timestamp ofa final supporter ssup ∈ S.

Hsup ⊆ Hssup The subset of the local history at ssup that must beforwarded to slc.

{refd|d ∈ D ∧ ssup ∈ DHd} The references of the shared data objects for whichssup is a data holder.

{refd|d ∈ D ∧ ssup = wmd} The references of the shared data objects for whichssup is the write master.

{(refd, idm)|d ∈ D ∧ m ∈MMd ∧ CL

ssupm 6= ∅}

A set of tuples that contains the references and theidentifiers for those methods for which the support-ing site registered a call-listener.

{(nameclassd, idm)|d ∈ D ∧

m ∈ MMd ∧ CLssupm 6= ∅}

A set of tuples that contains the class names andthe identifiers for those methods for which ssup reg-istered at least one call-listener.

Table 10.5: Final state support message

Whenever the latecomer’s site slc receives a final state support message from afinal supporter ssup, it adds the contained messages to its message buffer MBslc . Asevery final supporter locally determines the set Hsup, the latecomer’s site slc canreceive some messages twice. However, as these messages are uniquely identified by


their timestamp, slc simply replaces them in the message buffer. Then slc uses thefurther content of the message to update or create the sets DHd and SCLm.

When the latecomer’s site slc received a final state support message from everyparticipating site, and the sites that had to send one, but did not do so left thesession, slc received all necessary messages to balance the initial state and locallyre-executes the content of the message buffer MBslc according to the order givenby the timestamps of the messages. The latecomer’s site slc does not re-executea method call, if this call is directed to a data object d with slc 6∈ DHd. If theresult of such a method call is needed by another distributed action, slc looks up thecorresponding method call result message in the message buffer. As slc is included inthe result-distribution phase of every method call that was initiated by a modifyingdistributed action, slc must have received the result message. Until the messagebuffer MBslc is not empty, the latecomer’s site slc adds all messages that it receivesto the message buffer. As the local re-execution does not cause any network traffic,it is much faster than the execution in a distributed context. This ensures that themessage buffer gets empty.

As soon as the message buffer MBslc is empty, the latecomer’s site slc distributesa join complete message to all other sites and starts all applications that are definedin the session profile. From now on, the latecomer’s site slc does not buffer messagesanymore, instead it handles a received message according to the corresponding dis-tributed action. Similarly, the other participating sites only include the latecomer’ssite slc in the message exchange for a distributed action, if the distributed actiondemands this.

Though the latecomer now joined the session, a final supporter ssup still canreceive messages that the latecomer’s site slc needs. Fig. 10.5 illustrates this problem.In this figure, the user at site s4 joins the session as a latecomer. After site s4

initialized the connections to the other sites, it chooses the site s3 as the initialsupporter. The site s3 supplies the latecomer’s site s4 with an initial state. Thenthe latecomer’s site s4 distributes a final state request message to all participatingsites. Before the site sd.m

1 can serve the request of the site s4, it leaves the session.However, the sites s2 and s3 serve the request of the latecomer’s site s4. After theydistributed the final state support message, they receive a method call message fromthe site sd.m

1 . As sd.m1 distributed this message, before s4 initialized its connections,

sd.m1 did not send the message to s4. As result, the sites s2 and s3 execute the method

call d.m and the latecomer’s site s4 does not.For this reason, each final supporter ssup has one further task, after it sends the

final state support message to the latecomer’s site slc. Whenever a final supporterssup receives a message or adds a message to its local history, it checks, whether themessage must be forwarded to the latecomer’s site or not. Again, a final supporterssup must forward a message from a site s ∈ S, if

• its timestamp ts is lower than the connection timestamp tss→slc,

• its timestamp ts is not in the set of timestamps included in the final staterequest message, and

• the message is directed to an object d ∈ D with slc ∈ DHd.


t t t

CON: Connecting message FSR: Final state request message

FSS: Final state support message IOS: Initial object support message ISF: Initial support finished message ISR: Initial state request message MC: Method call message

CON

t

CON

CON

CON

IOS

ISF

FSR

FSS

MC

d .m

FSS

ISR

d .m

d .m

m . d 1 s

2 s 3 s 4 s

Figure 10.5: Final phase problem

When the latecomer’s site slc receives such a delayed message from a final supporter,it either adds it to the message buffer, if it is still re-executing the content of themessage buffer MBslc , or executes it directly.

The latecomer’s site slc supplied each final supporter with the set of its connectiontimestamps. With the help of these connection timestamps, a final supporter canfinish the above task as soon as

1. it either received from every site s ∈ S a message with a timestamp ts > tss→slc

or

2. every site s ∈ S for which the latecomer provided a connection timestamp leftthe session.

In the first case, a final supporter ssup cannot receive a message with a timestampts < tss→slc

from another site s ∈ S anymore, as the network kernel interface (NKI)of DreamTeam (see section 2.1) ensures that messages are delivered in order. In thesecond case, a final supporter can be sure that he does not receive such a message,as the NKI offers a reliable multicast service that blocks a sender until the messagewas delivered to all recipients. In DreamObjects, it is assumed that such a multicast

10.2. REPLAY 133

is not aborted and therefore either all or none of the defined recipients receive themessage. Thus, a site cannot receive a message from a site that already left thesession.

10.2 Replay

DreamObjects allows a latecomer to join a session with a replay that shows how thecurrent state was reached. Chung et al. [CDR98] describe such a service for a centralarchitecture. The service is based on a latecomer accommodation server which iscalled the logger. At the site of a participant, a so-called loggable captures all eventsthat change the local user interface and sends these events to the logger. So thelogger is informed about all changes that a client applies to the user interface of ashared application. When a latecomer wants to join a session, the logger replays alllogged events to the latecomer’s loggable. Based on these events, the latecomer’sloggable creates the user interface. As the log can become very large, the systemuses log compression techniques. These compression techniques depend on semanticinformation about the events that a loggable has to provide. Instead of replaying allevents, e.g. mouse movements, the logger can provide the latecomer with the eventsthat resulted in a state change.

In [MP94, MP95b, MP95a], Manohar and Prakash present a session capture andreplay paradigm for asynchronous collaboration. A single-user session is encapsu-lated and recorded in a so-called session object. Users collaborate asynchronouslyby annotating, by modifying, and by exchanging these session objects. The runtimesystem allows to replay a session object at different speeds according to a user’srequirements. A similar service is also offered by RTP/I [Mau00b].

Compared to the above approaches, DreamObjects supports a join with a re-play for synchronous collaboration and does not rely on a central server that logsall events. The basic idea is to let the latecomer’s site select a participating sitethat supports it with the complete history list H and the rest of the information alatecomer needs to participate in the session, e.g. the set of data holders. The late-comer’s site uses the stored messages in the history list H to re-execute the modifyingdistributed actions and thus to replay how the session state was reached. As thehistory list only contains the messages that resulted in a state change, compared to[CDR98], additional compression techniques are not necessary.

As the latecomer’s site re-executes all distributed actions, it automatically be-comes a data holder of all shared data objects. At least until the next evaluation ofthe adaptively distributed shared objects. Thus, a join with a replay is not possible,if the application uses shared data objects with an asymmetric distribution schemeto share any site-specific data. In this case, the distributed actions that were di-rected to such data objects cannot be re-executed. Therefore, an application has toindicate, whether it supports a join with a replay or not. When all applications thatare used in a session, support a join with a replay, a latecomer can decide, whetherhe joins with a replay or not.

For a join with a replay, some mechanisms of DreamObjects must be adapted.These adaptations are only used, if all applications that are used in a session support


a join with a replay.As DreamObjects only distributes a message for a distributed action to those

sites that have to receive it, it is possible that the complete history Hd of a shareddata object is not available. Consider, e.g., a partially-replicated data object d. Thesite sd created the data object and thus is a data holder of d. As at least |DHd| ≥ 2,the evaluator chooses one further site to become a data holder (see section 7.1). Asboth sites are informed about every modifying distributed action that is applied tothe data object d, they know the complete history Hd. Now imagine, that furthersites join the session with a direct state transfer and the evaluator decides thatthese sites also become data holders. The direct state transfer ensures that thesesites receive a consistent state of d, but not the complete history Hd. Thus, when thefirst two data holders leave the session, there is no site left that knows the completehistory Hd. To ensure that there is always a site that knows Hd, the direct statetransfer mechanism has to be adapted. For this reason, the initial supporter ssup ∈ S

adds instead of the timestamps the corresponding subset of the history list to eachinitial object support message (see table 10.2) for an object d ∈ D, i.e.

{Hssup

di|di ∈ ({d} ∪ (I

ssup

d \ Dlc))}

As the initial supporter ssup is itself a data holder of these objects, it knowsthe complete history of each shared data object in Dsup and thus slc receives thecomplete history. Thereby, the history Hd for a data object d is preserved for a joinwith a replay.

Though every data holder now knows the complete history of a data object, ajoin with a replay can still be impossible, when a data object d ∈ D is deregisteredand all of its data holders left the session. Then there is again no site left in thesession that knows the history Hd and forwards it to the latecomer’s site for re-execution. To solve this problem, DreamObjects does not really deregister a shareddata object, when the application that registered it supports a join with a replay.Instead of removing the shared data object from the registry, it is just marked asderegistered and cannot be requested anymore. When a site joins the session thatwould normally become a data holder of a deregistered data object, it still receivesit and its history. However, if a user stores a session state (see section 9.2.1), theruntime system skips the shared data objects marked as deregistered.

With these adaptations a join with a replay is always possible. As for a joinwith a replay the same problems as for a direct state transfer have to be solved, thelatecomer support again is split up in three phases, i.e. a connection, an initial, anda final one. The following sections describe these phases.

10.2.1 Connection Phase

If all applications that are used in a session indicate that they support a join witha replay, a user can select this kind of latecomer support in the session window ofDreamTeam (see fig. 10.4). If he selects a join with a replay, the runtime systemopens a configuration dialog like in fig. 10.6. This dialog window allows a userto select how many percent of the session state are replayed visually. Of course,

10.2. REPLAY 135

the runtime system has to replay all distributed actions, but only the specifiedpercentage is shown in the user interface. Additionally, a user can define the delaybetween two replayed distributed actions and thus the speed of the replay. Duringthe replay, he can use the dialog window to vary the speed. As soon as the userconfirms his configuration the connection phase is started.

Figure 10.6: Configuration dialog for a join with a replay

Like in the connection phase of a direct state transfer (see section 10.1.1), thesession manager of DreamTeam ensures that the latecomer’s site slc is added to S.The latecomer’s site slc establishes a connection to all other sites in S, stores therespective connection timestamp, and informs the sites that it wishes to join with areplay instead of a direct state transfer.

All sites partly include the latecomer’s site slc in the message exchange for themodifying distributed actions. The latecomer’s site stores all messages that it re-ceives in a message buffer MBslc . Compared to the direct state transfer, the late-comer’s site slc does not receive any method call result messages, as it becomes adata holder of all shared objects and thus it can determine the result of a methodcall locally during the replay.

10.2.2 Initial Phase

Like in the initial phase of a direct state transfer (see section 10.1.2), the latecomer’ssite slc first selects an initial supporter ssup ∈ S and sends an initial support requestmessage to this site. Compared to the direct state transfer, an initial supporter doesnot have to transfer the state of an object. Instead it has to supply the latecomer’ssite with the complete history Hd of each shared data object d ∈ D.

Let Dsup denote the set of objects whose histories have to be transmitted tothe latecomer’s site slc and let Dlc denote the objects whose histories already weretransmitted to slc. When the initial supporter ssup receives an initial support requestmessage, it sets Dsup to D. Then the initial supporter ssup sends an initial historysupport message for each shared data object d ∈ Dsup and ssup ∈ DHd to slc. Table10.6 shows the content of such a message. In addition to a timestamp of the initialsupporter ssup, this message contains the reference of the shared data object and ofcourse its history.

After the initial supporter ssup sent the message, it removes the data object d

from the set Dsup. When the latecomer’s site slc receives an initial history supportmessage, it adds the received subset of the history list to the message buffer MBslc

and stores the reference of the object.



refd The reference of the shared data object whose history list is transferred.

Hd The history list of d.

Table 10.6: Initial history support message

The initial supporter ssup again supports the latecomer’s site slc on a per-objectbasis. When the first initial supporter fails, the latecomer’s site selects a new initialsupporter. The new initial supporter can resume the support and does not have tostart from the beginning.

Depending on the distribution schemes of the shared data objects, it is possiblethat the initial supporter ssup is not a data holder of every data object in D. Inthis case, the set Dsup is not empty now. To supply the latecomer’s site with thehistory of the remaining objects in Dsup, the initial supporter selects a data holderof every remaining object and requests this data holder to support the latecomer’ssite slc with the corresponding subset of the history. For this reason, it sends aninitial history support request message (see table 10.7) to the selected data holder.The data holder that receives such a request message supports the latecomer’s siteslc with the requested subset of the history list. For this purpose, it sends an initialhistory support message to slc. After supporting the latecomer, the data holdersends a confirmation message to the initial supporter ssup. As soon as the initialsupporter receives such a confirmation, it removes the corresponding object from theset Dsup. Finally, when the set Dsup is empty, the initial supporter sends a messageto slc to indicate the end of the initial phase.


idslcThe identifier for the latecomer’s site.

refd The reference of the shared data object whose history list has to besent to slc.

Table 10.7: Initial history support request message

10.2.3 Final Phase

Like in the final phase of the direct state transfer (see section 10.1.3), the latecomer’ssite may not have received all messages that are necessary to join the session. Forthis reason, the join with a replay also uses a final phase.

As soon as the latecomer’s site slc received the message that indicates the endof the initial phase, it distributes a final history request message to all other sites.Table 10.8 shows the content of such a message. Besides a timestamp of slc, thismessage contains the connection timestamps that the latecomer stored during theconnection phase and the timestamps of some messages that slc already received.

Again, each site ssup ∈ S that receives such a message is called final supporter.When a final supporter ssup receives a final state request message, it adds the late-

10.2. REPLAY 137

ts The timestamp of the message, i.e. a timestampof slc.

{tss→slc|s ∈ S} The set of connection timestamps.

{ts|ts ∈ TSMBslc ∧ ts.id = ids

∧ts < tss→slcfor all s ∈ S}

The timestamps of the messages in MBslc witha timestamp that is less than the correspondingconnection timestamp.

Table 10.8: Final history request message

comer’s site slc to all sets DHd, as slc becomes a data holder of all data objects.Then each final supporter ssup checks, if its local history list contains messages thatthe latecomer did not receive by now, but has to receive to get a complete historylist. For this reason, a final supporter searches in its local history list for messagesthat were sent by a site s ∈ S and which timestamp ts

• is lower than the corresponding connection timestamp tss→slcand

• is not contained in the set of timestamps that the latecomer’s site slc alreadyknows.

When a final supporter ssup finds such messages, it forwards them to the latecomer’ssite.

Let Hsup ⊆ Hssup denote the subset of messages that a final supporter ssup mustforward to the latecomer’s site slc. After ssup determined Hsup, it sends a final statesupport message to slc. This message has the same structure as during the directstate transfer (see table 10.5). When the latecomer’s site slc receives a final statesupport message from a site ssup, it adds the contained messages to its messagebuffer MBslc and updates or creates the sets DHd and SCLm.

When slc received a final state support message from every participating site andthe sites that had to send one, but did not do so, left the session, it starts to replaythe content of MBslc . Until the replay is not finished, the latecomer’s site slc addsany further messages that it receives to the message buffer.

For the replay, the runtime system at slc locally re-executes all initiating dis-tributed actions that are specified by messages in the message buffer MBslc . Afterre-executing an initiating distributed action, the runtime system removes the respec-tive message and the messages for follow-up distributed actions from the messagebuffer. If the latecomer specified that, e.g., only the last seventy percent of thesession state are to be replayed, the runtime system first opens the user interface,after it executed the first thirty percent of the distributed actions. As soon as themessage buffer MBslc is empty, the latecomer’s site slc distributes a join completemessage to all other sites. Then slc handles a received message according to thecorresponding distributed action. A site that receives a join complete message froma latecomer, only distributes a message for a distributed action to slc, if slc has toreceive it.

Like in the final phase of a direct state transfer, each final supporter ssup has onefurther task, as a final supporter ssup still can receive messages that the latecomer’s


site slc needs. Whenever a final supporter ssup receives a message or adds a messagefrom a site s ∈ S to its local history, it checks if the latecomer’s site slc needsthis message and in this case forwards the message to the latecomer’s site. Whenslc receives a such delayed message from a final supporter, it either adds it to themessage buffer, if it is still re-executing the content of MBslc , or executes it directly.If a final supporter received from every site s ∈ S a message with a timestamp ts

that is higher than the connection timestamp tss→slc, it finishes this task.

Chapter 11

Data Distribution

DreamObjects supports a variety of distribution schemes. The previous chaptersdescribed distributed actions, latecomer support, and services for data persistence.Every described service and distributed action respects the distribution scheme ofthe underlying shared data object. This chapter in detail describes the differentsupported distribution schemes and the configuration possibilities for a developer.DreamObjects distinguishes between static and adaptive distribution schemes. Anadaptive distribution scheme changes the set of data holders depending on how asite accesses a shared data object. In a static distribution scheme, the set of dataholders is predefined and does not change depending on the access pattern of a site.

Each distribution scheme is controlled by an evaluator. DreamObjects offers twopredefined evaluators for static distribution schemes. One implements the asymmet-ric distribution scheme and one the replicated distribution scheme. DreamObjectsalso offers two predefined evaluators for adaptive distribution schemes: a user-oriented and a network-oriented one. Apart from the predefined evaluators,DreamObjects defines an interface that permits developers to define and introducetheir own distribution schemes. The following sections describe the predefined staticand adaptive distribution schemes and how developers can define their own distri-bution schemes.

11.1 Static Distribution Schemes

The runtime system uses an evaluator for a static distribution scheme to

1. determine the set of data holders DHd, when a shared data object d is regis-tered,

2. to determine, whether a latecomer’s site becomes a data holder of a data objectd, and

3. to sort the data holders in DHd, when a site s 6∈ DHd executes a readingmethod call.

A static evaluator can decide if a participating site becomes a data holder whenit joins the session or when a new object is created. Additionally, a static evaluator

139

140 CHAPTER 11. DATA DISTRIBUTION

can determine which site executes a reading method call and so balance the loadbetween the different data holding sites. Thereby, it is possible to define arbitraryfurther static distribution schemes. If a developer, e.g., develops an applicationthat is used in a predefined network, he can define his own evaluator and onlydistribute a shared object to the sites that have a good network connection. For thispurpose, a developer has to extend a basic Evaluator class and implement threemethods: getDataHolders, becomesDataHolder, and sortDataHoldersForRead.The runtime system calls these methods in the respective cases. Fig. 11.1 shows thecorresponding class hierarchy.

+getDataHolders()

+becomesDataHolder()

+sortDataHoldersForRead()

Evaluator

ReplicatedEvaluator AsymmetricEvaluator

Figure 11.1: Class hierarchy of static evaluators

The predefined evaluator for the asymmetric distribution scheme fits well, whena developer wants to allow the users of a collaborative session to introduce localdata, e.g. a video that is stored in the local filesystem of a user. With the helpof the asymmetric distribution scheme, each site can access the video like a localobject without transferring the complete video. The replicated distribution schemefits well, when every participating site often accesses and modifies the data object.In this case, the replicated distribution scheme decreases the response time of theapplication.

For the predefined distribution schemes, the results of the methods are quiteobvious. The getDataHolders method for an asymmetric distribution scheme re-turns a set that only contains the object creating site {sd}, while the one for thereplicated distribution scheme returns the set of participating sites S. The resultsof the becomesDataHolder method are also clear, as in the asymmetric distributionscheme no latecomer’s site becomes a data holder and in the replicated case everylatecomer’s site becomes a data holder. Eventually, the sortDataHoldersForRead

method for the asymmetric distribution scheme can only return the object creatingsite sd. If the shared object uses the replicated distribution scheme, every site holdsthe data of the object and the sortDataHoldersForRead method is never called.However, if called, it of course returns the respective local site.

11.2 Adaptive Distribution Schemes

In case of a static distribution scheme, the set of data holders only changes, wheneither a site joins the session or leaves the session. In case of an adaptive distribution

11.2. ADAPTIVE DISTRIBUTION SCHEMES 141

scheme, the set of data holders can also change depending on how a site accesses ashared data object.

For this purpose, the post-execution phase of every method call is extended.Whenever a method call initiating site sd.m executed a method call d.m, it informsthe respective local evaluator for d about d.m. It passes the name of the methodnamem, a boolean value that indicates, whether the method call modified the contentof the object or not, and the size sized of the shared data object in bytes to theevaluator. Based on this information and the information about previous methodcalls, the evaluator can initiate a change in the set of data holders DHd.

Remember that DreamObjects associates a write master wmd ∈ DHd with everyshared object. When a shared data object is created, the runtime system selects theobject creating site sd as write master wmd. DreamObjects only selects a new writemaster for a shared data object, when the current write master left the session. Forthis purpose, DreamObjects simply chooses the site sj ∈ DHd with the lowest siteidentifier idsj

as new write master. The write master of a shared data object playsa major role during all distributed actions. Concerning adaptive data distribution,the write master has an additional task. An evaluator for an adaptive distributionscheme has to specify a minimum number of data holders. To increase the availabilityof a data object, the specified minimum has to be greater than or equal to two. Theruntime system at the site of the write master wmd observes the number of dataholders |DHd|. When it falls below the specified minimum, it starts a protocol thatincreases the number to the specified minimum. This protocol uses the evaluator todetermine the sites that become new data holders of d.

+getDataHolders()

+becomesDataHolder() +sortDataHoldersForRead()

Evaluator

+methodCalled()

+getMinDataHolders()

+getNewDataHolders()

AdaptiveEvaluator

UserOrientedEvaluator NetworkOrientedEvaluator

Figure 11.2: Class hierarchy of adaptive evaluators

When a developer wants to develop an evaluator for an adaptive distributionscheme, he has to extend a basic AdaptiveEvaluator class (see fig. 11.2). Thus, adeveloper additionally has to implement the following methods:

1. methodCalled: This method is called by the runtime system, whenever the lo-cal site initiated a method call. Based on the passed information, the evaluatorhas to decide if the distribution of the shared object has to be changed.


2. getMinDataHolders: This method has to return the minimum number of dataholding sites.

3. getNewDataHolders: When the number of data holding sites falls below thedefined minimum, this method has to determine the sites that become a dataholder.

DreamObjects offers a user-oriented evaluator and a network-oriented one. Bothevaluators are based on the following ideas:

1. If a site s 6∈ DHd intensively accesses a shared data object d ∈ D, it shouldbecome a data holder. Then the site can execute reading method calls locallyand thus the response time of the collaborative application at site s decreases,when it executes a reading method call on d.

2. If a site s ∈ DHd does not access a shared data object d ∈ D frequently,it should give up its role as a data holder. So the number of data holdingsites is reduced. This decreases the number of messages that are necessary tokeep a shared data object consistent and thus reduces the response time of anapplication at every site, when it modifies the shared data object.

While the user-oriented evaluator realizes just these ideas, the network-orientedone additionally attempts to optimize the distribution of a shared data object withregard to the underlying network structure of the collaborating group. A developershould choose the user-oriented distribution scheme, if the data of an applicationcan be divided into single logical pieces. For instance, consider a collaborative texteditor. A text document is structured into single logical pieces, i.e. words, sentences,paragraphs, sections, and chapters. Depending on the kind of collaboration thata developer wants to support between the users of the collaborative text editor,he can use a shared data object for every single word, sentence, etc. of the textdocument. Normally, only a few users of a text editor work at the same logical pieceof the document. The user-oriented distribution scheme takes this into account anddistributes a data object to those sites that intensively access it.

A developer should use the network-oriented distribution scheme for shared dataobjects that are rarely changed and that are mostly accessed with reading methodcalls, e.g. shared data objects that contain the configuration of a shared application.In this case, the network-oriented distribution scheme reduces the network trafficand thus decreases the response time of an application.

Compared to the algorithms presented by Wolfson et al. [WJ92a, WJ92b, HW93],DreamObjects does not demand a special network topology, e.g. a star-based or tree-based network. In [WJH97], Wolfson et al. present an algorithm that can be usedwith general networks, but, e.g., a data holding site has to know its neighbors inthe network and how they access a shared data object. Based on this information,a data holding site decides, if its neighbor has to become a data holder or not. Thiscannot be ensured in DreamObjects, as the distributed action for a reading methodcall does not involve all data holding sites. Instead, DreamObjects uses an approachin which the sites decide on their own, if they become a data holder or give up theirrole as a data holder.


11.2.1 User-oriented Adaptive Distribution

The evaluator for the user-oriented adaptive distribution scheme adapts the distri-bution of a shared data object to the working style of the collaborating users. Thedata of the object is just distributed to those sites that intensively access it. As auser’s working style can change during a collaborative session, the evaluator reflectsthese changes in the distribution of the shared data object.

When a new partially-replicated object d ∈ D is created, the evaluator selectstwo of the participating sites as initial data holders, as two is the minimum of dataholders. A developer can increase this value. However, one of the data holdingsites is the object creating site sd, which also becomes the initial write master wmd.To select the other data holders for the shared data object, the evaluator choosesthe sites with the fastest network connection, according to their configuration inDreamTeam, and the lowest site identifiers as data holders for the new shared object.

When a site s 6∈ DHd initiates a reading method call, one of the data holdingsites has to execute the method call. It is the task of the evaluator to determinethis site. For this purpose, the evaluator sorts the data holding sites according totheir configured connection type and identifier. The site with the best availableconnection type and the lowest identifier is put into the first place of the sorted list.The distributed actions for the reading method calls select the first site in the listto execute the method call. If this site fails, the next one is selected, until there isno site left in the list or the method call was executed.

When a site joins a session, the evaluator has to decide, whether this site becomesa data holder of d. If a latecomer’s site joins the session with a direct transfer of thesession state (see section 10.1), it only becomes a data holder, if |DHd| is lower thanthe defined minimum. If a latecomer’s site joins with a replay (see section 10.2),it becomes a data holder, as the state of the object is inherently transferred to thelatecomer’s site.

To adapt the distribution of a shared data object to the working style of thecollaborating users and thus change the set of data holders, the evaluator observes,how a site accesses and uses a data object. It uses the provided information aboutevery method call that is initiated by the local site to calculate

• an overall load,

• a read load, and

• a write load

in calls per second. The overall load includes all method calls that are initiatedby the local site, the read load the reading method calls, and the write load themodifying ones.

To calculate these values, the evaluator for a data object d at a site s counts howmany reading, modifying, and general methods of the data object the local site callsin a developer-defined period of time ∆t. After every period of time, the evaluatorcalculates new load values. All load values in calls per second are calculated in thesame way. When, e.g., olsd denotes the current value of the overall load at a site s


for a data object d, wold denotes the developer-defined weight of the last load value,and mcs denotes the number of all method calls in the last period of time ∆t, theevaluator calculates the new overall load olsd

′ as follows

olsd′ = olsd wold +

mcs

∆t(1 − wold), with 0 ≤ wold ≤ 1.

A developer can specify different weight values and can set minimum and max-imum limits for every load. When at a site s ∈ DHd a load falls below a minimumlimit, the evaluator decides that the site s does not need to be a data holder any-more. A site s can only give up its role as a data holder of d ∈ D, if it is not thewrite master wmd and the number of data holding sites |DHd| is greater than thedefined minimum. In this case, it distributes a data holder remove message (seetable 11.1) to all other sites to inform them. This message contains a timestamp ofs and refd. Thereby, every receiving site can remove s from the set of data holdersDHd. After s was removed from the set of data holders, it is not notified aboutmodifying method calls anymore. This reduces the network load.

ts The timestamp of the message, i.e. a timestamp of the site that givesup its role as a data holder.


Table 11.1: Data holder remove message

When the write master wmd receives a data holder remove message for a dataobject d ∈ D, it checks the number of data holding sites to ensure the availabilityof the data object. Because of the distributed setting, several sites can give uptheir role as a data holder at the same time. Thus, the number of data holdingsites can fall below the defined minimum. In this case, the write master wmd usesthe evaluator to determine new data holding sites. The evaluator sorts the sites inS \DHd according to their configured connection type and identifier. Again, the sitewith best configured connection type and the lowest identifier is put into the firstplace of the sorted list. After this, the evaluator removes the sites that just gave uptheir roles as data holders. Eventually, the write master wmd uses the remainingsites to increase the number of data holding sites (see section 11.2.3).

When at a site s 6∈ DHd a load exceeds a maximum limit, the evaluator decidesthat the site s has to become a data holder and calculates the expected transmissiontime of the shared data object. For this purpose, the evaluator determines the dataholder with the best connection type and, based on this connection type and thelocal connection type, the expected transmission time. By specifying a maximumtransmission time, a developer can prevent that large data objects are transferredto a site with a poor connection type. If the expected time is below the developer-defined maximum, the evaluator starts the protocol to request the state of the dataobject (see section 11.2.3). After the protocol finished, the site s is a data holder.

It is an application- and network-dependent task to choose appropriate limits.For best results, a developer can test an application in the simulation environment


of DreamTeam (see section 2.1) and empirically determine appropriate limits. Oth-erwise, he can use the default values of the evaluator that were tested with severalsample applications and that provide a good starting point.

11.2.2 Network-Oriented Adaptive Distribution

The network-oriented distribution scheme attempts to optimize the distribution ofa shared data object with regard to the underlying network structure of the collabo-rating group. When a new partially-replicated object d ∈ D is created, the evaluatordetermines a partition of subsets SNi:

S =n⋃

i=0

SNi, with n ∈ N

For this purpose, the evaluator checks the IP address of every site. Sites whoseIP address only varies in the last octet are assumed to be in one subnet and addedto one subset SNi. After this, the evaluator selects one site from every subset SNi

as a data holder of the new shared object. For the subset SNi with sd ∈ SNi, theobject creating site sd is chosen as the data holding site. In the other subnets, theevaluator chooses the site with the fastest configured network connection and thelowest site identifier. This is done for the following reasons:

• Usually, sites in a subnet have a good network connection to each other, i.e.there is a low network delay and a high transfer rate between the sites. If onesite s in a subset SNi is a data holder of a shared data object d ∈ D, the othersites in the subnet can access d via s.

• As only one site in every subnet becomes a data holder of the shared data ob-ject, the number of data holders, compared to, e.g., the replicated distributionscheme, is reduced. Especially for distributed actions that modify the contentof the data object, this decreases the network load and thus the response timeof an application.

Again, the minimum of data holding sites is defined as two, but a developer canincrease this value. When a new shared object is created, the evaluator selects onesite from every subnet to become a data holder. Of course, the object creating sitebecomes a data holder. If the participating sites cannot be divided into as manysubnets as the defined minimum of data holding sites, the evaluator sorts the sitesaccording to their specified network connections and site identifiers. From thesesites, the evaluator selects as many sites as are necessary according to the definedminimum.

When a site joins a session, the evaluator has to decide, whether this site becomesa data holder of d. If the latecomer’s site joins with a replay (see section 10.2) ofthe reached session state, it automatically becomes a data holder of d. In the othercase, the evaluator checks, if the joining site belongs to one of the subsets SNi. Inthis case and if |DHd| is greater than or equal to the defined minimum, a latecomer’ssite does not become a data holder. The number of data holders has no influence,


if the latecomer’s site is the first site of a new subnet. Then the latecomer’s sitebecomes a data holder.

When a site s 6∈ DHd executes a reading method call, it is the task of the evaluatorto determine a sorted list of data holding sites. For this purpose, the evaluator sortsthe list of data holding sites as follows. For a site s ∈ SNi, the data holding sites inthe same subnet, i.e. SNi∩DHd, are put into the first places. After the data holdingsites from the same subnet SNi were added to the list, the evaluator adds the rest ofthe data holding sites to the list. Again, data holding sites with a better configuredconnection type and a lower site identifier are rated higher than others.

The first data holder in a subnet is chosen depending on its connection type,but there can be sites in the same subnet that access the data object more oftenthan other sites, especially than the data holding site. As this cannot be known atregistration time of the shared data object, the evaluator uses the information thatis provided about each method call to calculate the overall load, read load, and writeload in bytes and calls per second. Loads are calculated in the same way as for theuser-oriented adaptive distribution scheme (see section 11.2.1).

A developer can set minimum and maximum limits for the different loads andthe maximum transmission time for the shared data object. When at a site s 6∈ DHd

a load exceeds a maximum limit and the expected transmission time is below thedeveloper-defined maximum time, the evaluator decides that the site s has to becomea data holder and starts the corresponding protocol (see section 11.2.3). After theprotocol finished, the site s is a data holder.

When at a site s ∈ DHd a load falls below a minimum, the evaluator decidesthat the site s has to give up its role as a data holding site. However, a site s onlygives up its role as a data holder and distributes a data holder remove message (seetable 11.1) to all other sites, if

• there is another data holding site in the same subset,

• the number of data holders is greater than the defined minimum, and

• it is not the write master wmd of the shared data object.

The network-oriented adaptive distribution scheme attempts to ensure that thereis at least one data holder for every subnet to which the other sites in the same subnetcan direct reading method calls. Because of this, a site must not give up its role asdata holder, if there is no other data holding site in the same subset.

The write master must not give up its role as a data holder, as it observes thenumber of data holders. The number of data holders can decrease, because sitescan leave the session or give up their role as a data holder. However, if |DHd| fallsbelow the defined minimum, the write master uses the evaluator to determine newdata holders. For this purpose, the evaluator checks if there are subnets without adata holding site. In this case, it selects from every subnet one site that has the bestconfigured connection type and the lowest site identifier to become a data holder.If it is still necessary to determine more data holders, the evaluator selects the sitesfrom S \DHd with the best configured network connection and lowest site identifier.The evaluator does not select a site that just gave up its role as a data holding


site. Then the write master uses the remaining sites to increase the number of dataholding sites (see section 11.2.3).

11.2.3 State Transmission Protocol

This protocol transfers the state of a shared data object d ∈ D from a supportingsite ssup ∈ S that is a data holder of d to a requesting site sreq ∈ S that is not adata holder of d. The protocol is initiated for three reasons:

1. When the number of data holders |DHd| falls below the defined minimum,the write master wmd uses the evaluator to determine how many sites arenecessary to raise the number of data holders above the defined minimum.Then the write master wmd requests these sites to initiate the protocol.

2. The evaluator for a data object d decides that the local site has to become adata holder and therefore initiates the protocol.

3. When a site wants to store a shared data object d ∈ D (see section 9.1.1) orthe session state (see section 9.2.1) which includes d ∈ D, but is not a dataholder of d, it uses this protocol to become a data holder.

In the first case, the write master wmd noticed that the number of data holders|DHd| fell below the defined minimum. The write master wmd locally determines thesites that have to become a data holder to raise |DHd| above the defined minimum.For this purpose, the write master wmd uses the evaluator. The evaluator returns asorted list of sites that currently are not a data holder of d. Then the write masterwmd sends a message to as many sites in this sorted list as are necessary to raise|DHd| above the defined minimum. This message contains the reference refd and atimestamp of wmd. Like in the second and third case, a site that receives such amessage, starts the protocol to request the state of d.

A site sreq 6∈ DHd that wants to become a data holder has to choose a sitessup ∈ DHd that transmits the state of d. For this purpose, the site sreq uses theevaluator for d to sort the set of data holders DHd, as if it wants to execute a readingmethod call. Then the requesting site sreq sends an object state request message tothe first data holder. If the state transfer fails, e.g. the selected data holder leaves thesession, the site sreq selects the next data holder and sends an object state requestmessage to the respective site.

Table 11.2 shows the content of such a request message. The message containsa timestamp of the requesting site sreq and the reference of the data object. Thisallows the supporting site ssup to start the protocol and to supply sreq with the stateof the d. The message also contains the timestamps of the messages in the localhistory H

sreq

d , when

• all applications that are used in the session support a join with a replay, or

• the requesting site sreq once was a data holder of the data object d.


If a join with a replay is possible, the set of timestamps is used to provide therequesting site sreq with the complete history Hd of the data object d. When thesite sreq once was a data holder of d, the set of timestamps is used to determine, ifthe site sreq still has a consistent state of the data object. This is possible, when thedata object d was not modified, since sreq gave up its role as a data holder d.

ts The timestamp of the message, i.e. a timestamp of sreq.

refd The reference of the requested object.

TSHsreqd

The timestamps of the messages in Hsreq

d .

Table 11.2: Object state request message

Independent of what caused a site sreq to become a data holder of d, finallya site ssup ∈ DHd receives an object state request message. Upon reception, thesupporting site ssup locks the object to ensure that the object is not modified duringthe protocol. This is necessary, as it is not possible to re-execute method calls thatare directed to the data object d. A re-executed method call may use informationthat is provided by other data objects. Compared to the latecomer support (seechapter 10), these data objects may not be in the same state, as when the methodcall was executed for the first time. Thus, the re-execution can lead to a differentresult and an inconsistent state of the data object d.

As soon as the object is locked, i.e. the supporting site ssup holds the necessaryfloor or all locks were granted, the site ssup determines its further actions. When theobject state request message contains the timestamps of the messages in H

sreq

d andthe requesting site sreq once was a data holder of d, the supporting site checks, if thesite sreq still holds a consistent state, i.e. the local history H

ssup

d does not containany messages that are unknown to the requesting site. In this case, the site ssup

simply informs the requesting site sreq that it still is a data holder.When the requesting site sreq was not a data holder of d before, the site ssup

creates an object state transmit message. Table 11.3 shows the content of such amessage. It contains a timestamp of ssup and the requested data object d. If theobject state request message contains the timestamps of the messages in H

sreq

d andall applications in the session support a join with a replay, the object state transmitmessage contains the messages in H

ssup

d that are unknown to the requesting site sreq.This ensures that every data holder knows the complete history Hd and a join witha replay is possible.


d The requested object.

Hssup

d \ Hsreq

d The messages that are unknown for sreq.

Table 11.3: Object state transmit message

When the supporting site ssup sends this message to the site sreq, it replacesall shared data objects that the data object d contains with their corresponding


reference. The requesting site sreq just wants to become a data holder of d and notof the shared objects that d contains. The actual distribution of these shared objectsis handled by their own evaluators. When the requesting site sreq receives an objectstate transmit message, it replaces these references with the local instance of therespective data object. Thereby, the distribution of the contained shared objects ispreserved.

As the site sreq already joined the session, it has an instance of the data object d ∈D. This instance is either empty, when it was created with the default constructord.c0, or can contain an inconsistent state, when the site sreq was a data holder of d,but gave up this role in the past. This instance can be referenced by the applicationor other data objects. This reference cannot be exchanged, i.e. it is not possible toreplace the local instance of the data object with the received one.

A first idea to solve this problem is to supply the requesting site sreq with thehistory Hd and let sreq locally re-execute all missing modifying method calls. Asalready argued, the local re-execution is not possible. Instead, a developer has toimplement a special method for every shared data object that uses an adaptivedistribution scheme. As soon as the requesting site sreq receives the object statetransmit message, it calls the developer-defined method and passes the receivedinstance of the data object d as the argument. In this method, a developer has touse the received instance of the data object to set its state in the local instance ofthe data object.

After the state was set or after the supporting site ssup informed the requestingsite sreq that it is still a data holder, sreq adds itself to the local set DHd and sendsa data holder add message (see table 11.4) to all sites in S \ {ssup, sreq}. A sitethat receives such a data holder add message inserts sreq into the local set DHd andreturns a confirmation message to sreq. When the site sreq received a confirmationfrom every site, and the sites that did not send a confirmation left the session, sreq

sends a data holder add message to the supporting site ssup. Then ssup adds sreq

to the local set of data holders and unlocks the object. Confirmation messages arenecessary to ensure that every site knows about the new data holder sreq, beforessup unlocks the object and it is again possible to modify the data object d.

ts The timestamp of the message, i.e. a timestamp of sreq.


Table 11.4: Data holder add message

Chapter 12

System Implementation

DreamObjects consists of two parts: an object-oriented framework and a runtimeenvironment. Both are entirely implemented in Java [SUN02]. The object-orientedframework offers building blocks for the development of shared data objects andthe runtime environment offers services to manage the shared data objects of acollaborative application. A developer can access the services of DreamObjects viaan object manager that encapsulates these services.

DreamTeam offers a framework developer interface (FDI) which permits a devel-oper to extend the framework and to add managers to the manager layer (see section2.1). DreamObjects uses the FDI to integrate the object manager in the runtimeenvironment of DreamTeam. The object manager complements the DreamTeamplatform to cover the data domain of the programmer-centered clover model. Fig.12.1 shows the runtime integration of the object manager.

Runtime environment and control

Network, operating system, Java VM

Network

Kernel

Manager layer

Ap

pli

ca

tio

n s

erv

ice

la

ye

r (A

SL

)

Fra

me

wo

rk d

ev

elo

pm

en

t inte

rfac

e (F

DI)

Gro

up

wa

re a

pp

lic

ati

on

s Front-End

Rendezvous

manager

Node manager

Connection

manager

Archive manager

Session manager

Transfer

manager

Kernel layer

Persistency

kernel

System

protocol Network kernel interface

Network

kernel

Framework

extensions

Object Manager

Communication

layer

Service layer

Data layer

Figure 12.1: Runtime integration of the object manager in DreamTeam

151

152 CHAPTER 12. SYSTEM IMPLEMENTATION

By integrating the object manager via the FDI, groupware applications can accessits services via the application service layer and the object manager can access theoperating system with the network services, the Java virtual machine, and the kernellayer that offers low level services. The object manager is split in three layers: aservice layer, a data layer, and a communication layer. The service layer offers theservices as described in the previous chapters. The data layer consists of differentdata containers that are used by the service layer. The communication layer usesthe kernel layer of the DreamTeam platform and offers services to send, multicast,and receive messages. Fig. 12.2 shows the overall layered runtime architecture ofDreamObjects. The front-end and the groupware applications of the DreamTeamruntime architecture are subsumed in an application layer.

Service layer

Developer services System Services

Session state

persistency

Method call

distribution

Data

distribution

Latecomer

support

Substitute

generation

Concurrency

control

Data layer

Application layer Groupware application Front-end

Data

objects

Method

call stacks History Listeners Sites Session

states

Notification Data object

deregistration

Data object

registration

Data object

duplication

Data object

persistency

Data object

request

Substitute

classes

Data container

Adaptable service

Service

Communication layer

Message multicast Message unicast Message receipt

Figure 12.2: Layered runtime architecture of DreamObjects

Fig. 12.3 shows the class hierarchy for the integration of the object managervia the FDI of DreamTeam. The ObjectManager class extends the CSCWManager

class, i.e. the basic manager class that must be implemented by every manager,and implements the FDIListener interface. The CSCWManager class demands theimplementation of methods that are common to all managers. By implementingthe FDIListener interface the runtime system of DreamTeam informs the object

12.1. COMMUNICATION LAYER 153

manager, whenever a local user starts, joins, or leaves a session. So the objectmanager can determine, whether the local user is a latecomer or not. Additionally,the ObjectManager class implements the GroupStateListener interface. By im-plementing this interface and registering the object manager in the runtime systemof DreamTeam, DreamTeam informs the object manager, whenever a remote userjoins or leaves a session.

+getName()

+isAlive()

+terminate()

+terminationState()

CSCWManager

+someoneJoins()

+someoneLeaves()

+someoneLeavesCrash()

«Schnittstelle»

GroupStateListener

+sessionStarted()

+sessionJoined()

+sessionStopped()

«Schnittstelle»

FDIListener

ObjectManager

«Interface» «Interface»

Figure 12.3: Class hierarchy for the integration of the object manager

The following sections describe the different layers, present the main classesthat are used to implement them, and show how developers can use the services ofDreamObjects.

12.1 Communication Layer

The communication layer offers services to send, multicast, and receive messages.These services rely on the network kernel of DreamTeam (see section 2.1) and in-tensively use the Java serialization feature [SUN98]. The service layer handles thecommunication with the other participating sites via these services. Whenever a sitereceives a message, it uses the received timestamp to update its local logical clock.Whenever a site distributes a message, it automatically assigns a timestamp to themessage.

Fig. 12.4 shows the main classes of the communication layer. The object manageroffers an interface to the services of the communication layer:

• Message sendMessage(long site_id, Message msg, boolean response)

This method sends a message to the specified site. The message must be aninstance of the Message class. If the method has to wait for a response, thishas to be specified by a boolean value. Then the method waits, until it receivesa reply message, and returns the reply message.

• void replyMessage(long site_id, Message msg)

This method can be used to reply a received message.

• void sendMessage(ConnectionFilter cf, Message msg)

This method sends a message to the sites as specified by an instance of a class


that implements the ConnectionFilter interface. This interface demands theimplementation of an isIn method. The sendMessage method passes a siteidentifier to the isIn method and the isIn method has to decide, whether thespecified site has to receive the message.

• void multicastMessage(Message msg)

This message sends a message to all participating sites.

+getUserHosts()

+getUserHostAtID()

UserHostVector

+sendMessage()

+replyMessage()

+multicastMessage()

+registerMessageListener()

+deregisterMessageListener()

+getUserHostVector()

+getMessageListenerRegistry()

+getLogicalClock()

ObjectManager

+getTimestamp()

+setTimestamp()

Message

+getTime()

+getID()

Timestamp

DeveloperDefinedMessage

+addListener()

+containsListener()

+getListeners()

+removeListener()

MessageListenerRegistry

+messageReceived()

«Schnittstelle»

MessageListener

«Interface»

NetworkAccess

1

1

1

1 +run()

+getID()

+disconnect()

ConnectionReactThread

+isIn()

«Schnittstelle»

ConnectionFilter

«Interface»

1 1

1

1

+getTime()

+setTime()

+incrementTime()

+isNew()

LogicalClock

1

1

MethodCall MethodCallExecuted

TCPAccess MBoneAccess

Figure 12.4: Partial class hierarchy of the communication layer

To distribute messages, the object manager uses an instance of theNetworkAccess class that is provided by the DreamTeam platform and representsthe NKI. An instance of this class offers services that can be used for establish-ing network connections, sending, receiving, or multicasting messages. DreamTeamoffers different implementations of this class, e.g. TCPAccess or MBoneAccess. Bydefault, the object manager uses an instance of the TCPAccess class that maps allservices to TCP/IP. For each site that participates in a session, the object man-ager creates an instance of the ConnectionReactThread class. This class uses theinstance of the NetworkAccess class to receive messages.

Each exchanged message has to extend the basic Message class. The basic mes-sage class offers methods to set and read the timestamp of a message. For eachmessage type that is used in the different distributed actions, there is a special mes-sage class, e.g. MethodCall and MethodCallExecuted. If a developer, e.g., wantsto implement his own distributed lock, he has to exchange messages with the otherparticipating sites. For this purpose, he can lookup the participating sites and theiridentifiers via the instance of the UserHostVector class that is maintained by the

12.2. DATA LAYER 155

runtime system of DreamTeam and can access the services of the object manager todistribute messages. These messages must extend the DeveloperDefinedMessage

class. This message class is simply a subclass of the basic message class. With itshelp, the runtime system can distinguish system messages from developer-definedmessages and only informs a developer, when it receives a developer-defined mes-sage. To be informed, whenever the local site receives a developer-defined message,developers have to register a listener that implements the MessageListener inter-face that demands the implementation of a messageReceived method. To registera message listener, the object manager offers the following methods:

• void registerMessageListener(MessageListener listener)

Developers have to use this method to register a message listener.

• void deregisterMessageListener(MessageListener listener)

Developers have to use this method to deregister a message listener.

The object manager stores the registered message listeners in an in-stance of the MessageListenerRegistry class. Whenever an instance of theConnectionReactThread class receives a message, it checks, whether this messageis a developer-defined one. If this is the case, it looks up the registered messagelisteners and informs them about the received message.

12.2 Data Layer

The data layer offers access to different data containers. Via these containers, theservices can access the information they need for their execution. There are datacontainers for shared data objects, substitute classes, method call stacks, sessionstates, the different listeners, and the history.

Fig. 12.5 shows the main classes of the data layer. The object manager offersan interface that allows to access the instances of these classes at runtime. Thefollowing classes are used to maintain the information in the data layer:

• ObjectRegistry: This container holds the registry for the shared data ob-jects. The shared data objects can be accessed via their reference or via theirregistration name. Every shared data object implements the Substitute in-terface, which offers access to the representation of a shared data object, itsdata holders, or its current write master.

• ClazzLoader: This container holds the bytecode of the substitute classes thatthe runtime system generated.

• MessageListenerRegistry: This container holds the locally registeredmessage-listeners that are informed, whenever the local site receives adeveloper-defined message.

• CallListenerRegistry: This container holds the locally registered call-listeners and their configurations. Depending on their configuration, the reg-istered call-listeners are informed when a method call was executed.


• SiteCallListenerRegistry: This container holds information about the re-mote sites that registered call-listeners. The contained information is usedduring the distributed actions.

• ObjectListenerRegistry: This container holds the locally registered object-listeners that are informed, whenever a new shared object is registered.

• MethodCallStacks: This container holds the method call stacks that are nec-essary to handle nested distributed actions.

• SessionStateDatabase: This container holds the session states that wereeither stored locally or imported.

• UserHostVector: As already mentioned, the instance of the UserHostVector

class is maintained by the runtime system of DreamTeam. It contains infor-mation about the sites that participate in the session, e.g. their site identifiersor their connection type.

• History: This container holds the history list that is used during the latecomersupport.

+getObjectRegistry()

+getClassLoader()

+getMessageListenerRegistry()

+getCallListenerRegistry()

+getSiteCallListenerRegistry()

+getObjectListenerRegistry()

+getMethodCallingThreadRegistry()

+getSessionStatesFor()

+getUserHostVector()

+getHistory()

ObjectManager

+registerObject()

+deregisterObject()

+containsObject()

+getObject()

+getObjects()

ObjectRegistry

+addListenerConfig()

+getCallListenerConfigs()

+removeListener()

CallListenerRegistry

+addListener()

+getListeners()

+removeListener()

ObjectListenerRegistry

+addMessage()

+containsMessage()

+getMessages()

History

+addClassDefinition()

+getBytecode()

+isClassAvailable()

+loadClass()

ClazzLoader

+addSite()

+removeSite()

+getSiteListeners()

SiteCallListenerRegistry

+registerStack()

+deregisterStack()

+getStack()

+containsStack()

MethodCallStacks

+addState()

+removeState()

+getStatesFor()

+containsStatesFor()

SessionStateDatabase

+addDataHolder()

+getDataHolders()

+removeDataHolder()

+getWriteMaster()

+setWriteMaster()

+getRepresentation()

«Schnittstelle»

Substitute

+addListener()

+containsListener()

+getListeners()

+removeListener()

MessageListenerRegistry

+getUserHosts()

+getUserHostAtID()

UserHostVector

1

«Interface»

1

1 1

1

1

1 1

1 1

1 1 1

1

1

1

1

1

1

1

1 0..*

Figure 12.5: Partial class hierarchy of the data layer

Consider a user of a collaborative application who modifies a shared data objectd ∈ D by initiating a method call d.m with m ∈ MMd. The method call distributionis a part of the service layer. It can extract all necessary information from the datalayer, e.g. the sets CLm and SCLm via the instances of the CallListenerRegistry

12.3. SERVICE LAYER 157

and SiteCallListenerRegistry classes. The set DHd and the write master wmd

can be determined via the substitute for the shared object. Depending on theextracted information, it distributes a method call message via the communicationlayer and, if the site is not a data holder, eventually receives a method call resultmessage via the same layer.

12.3 Service Layer

The service layer offers the services as described in the previous chapters. Theyare encapsulated by an object manager. The services that are handled completelytransparent for a developer are called system services. The services that are calleddirectly by a developer are called developer services.

Fig. 12.6 shows the main classes of the service layer and the dependencies betweenthese classes and a sample shared data object class SampleObject. The followingmethods of the object manager provide access to the developer services:

• SharedObject registerObject(String classname,

String name,

Serializable[] args,

ConcurrencyControlScheme ccs,

Evaluator eval,

boolean persistent,

ApplicationReference appl_ref)

A developer has to call this method if he wants to register a new shared object(see section 7.1). In the given order, the arguments specify the class, theregistration name, the constructor arguments, the concurrency control scheme,the evaluator, the persistency, and the registering application of the new dataobject. As result, the method returns the substitute for the specified dataclass.

• SharedObject registerObject(String classname,

Serializable[] args,

ConcurrencyControlScheme ccs,

Evaluator eval,

boolean persistent,


If a developer wants to leave it to the runtime system to define a registrationname, he has to call this method to register a new shared object (see section7.1).

• SharedObject duplicateObject(SharedObject obj, String name)

A developer has to call this method to duplicate a shared object (see sec-tion 7.2). The arguments of this method are the shared object for which thedeveloper needs a duplicate and a registration name for the duplicate.


• SharedObject duplicateObject(SharedObject obj)

If a developer wants to leave it to the runtime system to define a registrationname, he has to call this method to duplicate a shared object (see section 7.2).

• void deregisterObject(SharedObject obj)

This method has to be called to deregister a shared object (see section 7.3).

• SharedObject getNamedObject(String name,


If a developer wants to request a shared object from the object manager, hehas to use this method. As arguments, he has to specify the registration nameof the shared object and the application that registered the shared object.

• SharedObject loadSharedObject(ApplicationReference appl_ref,

InputStream in)

This method allows a developer to load a shared object from the specifiedstream (see section 9.1.2).

• void saveSharedObject(SharedObject obj, OutputStream out)

This method allows a developer to write a shared object to the specified stream(see section 9.1.1).

• void registerCallListener(CallListener listener,

SharedObject obj)

This method allows a developer to register a call-listener that uses the event-based notification service and listens to state changes of a particular sharedobject (see section 5.1.2). The call listener has to implement the CallListenerinterface that demands the implementation of a handleMethodCallEvent

method.

• void registerCallListener(CallListener listener,

String classname)

A developer has to use this method, if he wants to register a call-listener thatlistens to state changes of shared data objects of a particular class (see section5.1.2).

• void registerCallListener(Object listener,

SharedObject obj,

MethodMapping[] mms)

This method allows a developer to register a call-listener that uses themapping-based notification service and listens to state changes of the specifiedshared object (see section 5.2). The mapping between the shared object andthe listener object is specified by an array of MethodMapping instances. Eachinstance specifies a method of the shared data object, a method of the listenerobject, and the arguments that have to be passed to the listener method.

12.3. SERVICE LAYER 159

• void registerCallListener(Object listener,

String classname,

MethodMapping[] mms)

This method allows a developer to register a call-listener that uses themapping-based notification service and listens to state changes of shared dataobjects of a particular class (see section 5.2).

• void deregisterCallListener(Object listener): This method allows adeveloper to deregister a call-listener (see section 5.1.2).

• void registerObjectListener(ObjectListener listener)

A developer has to use this method if he wants to register an object listener(see section 5.1.1). An object listener has to implement the ObjectListener

interface that demands the implementation of a handleObjectEvent method.

• void deregisterObjectListener(ObjectListener listener)

This method allows a developer to deregister an object listener (see section5.1.1).

«Schnittstelle» Substitute

+registerObject() +duplicateObject()

+deregisterObject() +getNamedObject() +saveSharedObject() +loadSharedObject() +registerCallListener() +deregisterCallListener() +registerObjectListener() +deregisterObjectListener() +lockObject() +releaseObject()

ObjectManager

ObjectStateTransmitter

ObjectRegistry

«Schnittstelle» SharedObject

«Interface»

+MODIFYING_METHODS

SampleObject

«Interface»

Latecomer

InitialSupporter

FinalSupporter

SubstituteGenerator

ScanForSessionStates

SORepresentation

SampleSubstitute ConcurrencyControlScheme Evaluator

MethodCallResultSentObserver

1 1

1

1

1

1

1 1

1

MethodCallSentObserver

ObjectLockRequester

Figure 12.6: Partial class hierarchy of the service layer

Depending on the used concurrency control scheme, the service for the concur-rency control either belongs to the developer services or the system services. Theconcurrency control scheme of a shared object is specified by an instance of the


ConcurrencyControlScheme class. It is specified and added to the representationof a shared object, when a developer registers a new shared object. The objectmanager can access the concurrency control scheme of a shared object via its objectregistry and use it to, e.g., lock an object during its duplication.

The concurrency control service is extensible and adaptable to application-specific needs. A developer can integrate his own concurrency control scheme byextending the ConcurrencyControlScheme class. Currently, DreamObjects offerstwo pre-defined concurrency control schemes. If a developer uses the predefinedmethod-based concurrency control scheme, the runtime system transparently han-dles the concurrency control and thus the concurrency control service belongs to thesystem services. If a developer uses the predefined object-based concurrency controlscheme, he explicitly has to request and release the floor (see section 6.1). For thispurpose, the object manager offers the following methods:

• void lockObject(SharedObject obj)

This method allows a developer to request the floor for an object that uses theobject-based concurrency control scheme. The method blocks until the sitereceives the floor.

• void lockObject(SharedObject obj, ObjectCCListener occl)

This method also allows a developer to request the floor for an object thatuses the object-based concurrency control scheme. Compared to the previousmethod, this method does not block, as the request is handled by a threadthat is specified by the ObjectLockRequester class. This thread notifies thespecified listener object as soon as the site receives the floor. The listenerobject has to implement the ObjectCCListener interface which demands theimplementation of a lockReceived method.

• void releaseObject(SharedObject obj)

A developer has to call this method to release the floor for an object that usesthe object-based concurrency control scheme.

The service to generate a substitute is a developer service as well as a systemservice, because a developer can either generate a substitute from the command-lineinterface or leave it to the runtime system (see section 7.1.1). It is encapsulatedin the SubstituteGenerator class. The SubstituteGenerator class uses the Javareflection feature [SUN97b] to generate a substitute class. With this feature, theservice can analyze a developer-defined data class, e.g. determine the set of con-structors and the set of methods or read the MODIFYING_METHODS field. Based onthis information, the service can create the necessary substitute class.

The rest of the system services is transparently handled by the runtime system.The data distribution service is controlled by an instance of the Evaluator class(see chapter 11). Like the concurrency control scheme, the evaluator for a sharedobject is specified at its registration. Currently, DreamObjects offers four predefinedevaluators for an asymmetric, a replicated, a user-oriented, and a network-orienteddistribution scheme. If none of the predefined evaluators fits the needs of an ap-plication, developers can define their own distribution scheme by extending the

12.4. APPLICATION LAYER 161

Evaluator class. Therefore, the distribution service is adaptable. At runtime, theevaluator of a shared object is used, e.g., by the object manager to determine thedata holders for a new shared object. The ObjectStateTransmitter encapsulatesthe state transmission protocol. This class, e.g., uses the evaluator to determine newdata holders for a shared object, when the number of data holding sites fell belowthe specified minimum.

The method call distribution service, as described in chapter 7 and 8, is han-dled in the substitute for a shared data object, e.g. in the SampleSubstitute

class in fig. 12.6. A substitute class uses the object manager to access the datalayer and to extract necessary information, e.g. the registered call-listeners. Italso accesses the communication layer via the object manager, to, e.g., distributemethod call messages. Some tasks during a method call are handled within sep-arate classes. The MethodCallSentObserver class implements a thread that ob-serves if the write master distributes a method call message. If this is not the case,it can take on the distribution of a method call message. In a similar way, theMethodCallResultSentObserver class observes if the write master distributes amethod call result message.

The latecomer support, as described in chapter 10, is handled by the Latecomer,InitialSupporter, and FinalSupporter class. The Latecomer class handles thenecessary mechanisms at the latecomer’s site. The InitialSupporter class containsthe necessary mechanisms for the site that was selected by the latecomer’s site asinitial supporter. The FinalSupporter class contains the necessary mechanisms forthe final phase of a latecomer support.

The services for loading, storing, or distributing session states are integrated inthe object manager (see section 9.2). To search for new session states the objectmanager uses an instance of the ScanForSessionStates class. Based on the con-figuration of the local user, this class scans a specified newsgroup or the incomingmailbox of the user.

12.4 Application Layer

The application layer contains the groupware applications and the front-end that isoffered by DreamObjects. The front-end mainly consists of the dialog windows thatallow a user to store, load, and distribute session states.

In order to use the services that are offered by DreamTeam (see chapter 2.1) andDreamObjects, the runtime system must have control over a collaborative applica-tion. For this reason, an application has to implement a certain interface, for whicha developer has

• to define the name and icon of the application,

• to offer methods to start and stop the application,

• to initialize the data of the application,

• to set a version number for the application, and


• to realize methods for configuration.

Fig. 12.7 shows the class hierarchy for a sample collaborative application. Themain class of the application has to extend the ObjectManagerAppl class, which isthe basic application class for all applications that use the services of DreamObjects.It demands the implementation of a createSharedData, loadSharedData, andbindSharedData method that are used to initialize the data of the application. ThegetReference method allows a developer to access the reference of the applicationthat is necessary to, e.g., register or load shared objects. The getObjectManager

method provides access to the local object manager.

+getName() +getIconImage() +getVersion()

+compatibleTo() +open() +close()

CSCWApplication

SampleApplication

+createSharedData() +loadSharedData() +bindSharedData() +createLocalSharedData()

+getReference()

+getObjectManager()

ObjectManagerAppl

+blockUserInterface() +releaseUserInterface()

«Schnittstelle» ReplayableAppl

«Interface»

ObjectManager

ApplicationReference

1 1

Figure 12.7: Class hierarchy of a collaborative application

The ObjectManagerAppl class extends the CSCWApplication class which is thebasic application class for DreamTeam applications. If a developer wants to usethe replay service (see section 10.2), the application further has to implement theReplayableAppl interface. The interface requires the implementation of a methodthat blocks the user interface during the replay and another that releases the userinterface after the replay.

The name and the icon of an application are used inside several overview andconfiguration windows inside the DreamTeam environment. A user can, e.g., opena window, which shows all icons of active applications. For this reason, a developerhas to implement the getName and getIconImage methods of the CSCWApplicationclass, which normally are no longer than one line of code.

In a distributed system, different program versions of the same application canrun inside the same session. This can cause serious problems, if, e.g., differentversions use different data representations. To address this problem, each version ofan application must have a unique version number [Rot00b].

12.4. APPLICATION LAYER 163

A single-user application usually provides a main method, which starts and ini-tializes the data of the application. Inside the application, a menu entry normallyallows to stop the application via an exit call. Inside the DreamTeam environment,the main program starts the runtime system, thus an application should not provideits own main routine. In addition, stopping the application with exit would stop theentire runtime system and therefore is forbidden.

Create shared data Request shared data

Open user interface

Create local shared data

Block user interface

Replay session state

Release user interface

[Joining]

[Otherwise] [Replay]

[Initiating]

Load shared data

[Loading]

Figure 12.8: Startup of a collaborative application

For seamless integration into the runtime system, an application has thereforeto provide its own methods for starting and stopping. Fig. 12.8 shows an UMLactivity diagram for the startup of a collaborative application. In DreamObjects,a collaborative application can be started because of different reasons. A user caninitiate a session and thus be the first user in the session. A user can load a sessionstate to resume previous collaborative work. In this case, he is also the first userin the session. Eventually, a user can join a session with a direct state transfer ora replay. In all these cases, the shared data of an application must be initialized indifferent ways. Therefore, DreamObjects distinguishes three startup modes:

1. Initiating : This mode indicates that the local user initiated the session towhich the application belongs. If an application is started in this mode, thecreateSharedData method is executed. A developer has to use this methodto create the shared data objects that are necessary to open the user interface.


2. Loading : This mode indicates that the local user loaded a session state. If anapplication is started in this mode, the loadSharedData method is executed.A developer has to use this method to bind the loaded shared data objectsto the application and possibly create new instances of non-persistent shareddata objects.

3. Joining : This mode indicates that the local user joined the session. If anapplication is started in this mode, the bindSharedData method is executed.As the user joined the session all shared data objects that are necessary to openthe user interface are already available. A developer has to use this methodto bind these shared data objects to the application.

After the data of an application were initialized, the runtime system opensthe user interface by calling the open method. If the local user joins with a re-play, the runtime system blocks the user interface with the blockUserInterface

method and replays how the session state was reached. As soon as the replayfinishes, the runtime system calls the releaseUserInterface method. Then thecreateLocalSharedData method is called and a developer can introduce local datato the session. When the local user did not join with a replay and, e.g., initiatedthe session, the createLocalSharedData method is directly called after the userinterface was opened.

Chapter 13

Application Development and

Reuse

In principal, there exist two approaches to develop collaboration-aware applicationswith the help of DreamObjects: from scratch or by reusing an existing single-userapplication. The latter approach is the more interesting one, as it reduces develop-ment costs and provides user with a well-known interface.

This chapter describes a three-step approach [LR01] that a developer can use totransform an existing single-user application into a collaborative one. The three-stepapproach relies on DreamTeam and DreamObjects. It combines the advantages ofthe collaboration-aware and collaboration-transparent approach: it keeps the qual-ity, the functionality, and the user interface of an existing single-user application,and converts the single-user application into a collaboration-aware application. Itillustrates that DreamObjects offers powerful services to manage shared data andthat it achieves a maximum of transparency for a developer.

Using the three-step approach an application can easily be transformed into amulti-user application. The steps are:

1. Integrate the application into the runtime system of the platform.

2. Organize shared data.

3. Add awareness services.

These steps cost considerable less efforts than a development from scratch. Usu-ally, a few hundreds lines of code are sufficient, even in larger programs with a totalof ten thousands lines of code. The first step was already described in the section12.4. To integrate an application into the runtime system an application has toextend a basic application class that is provided by the platform. This basic classenables the runtime system to control the application.

In the second step, a developer has to transform the data objects of a single-userapplication into shared data objects of a collaborative application. For this purpose,he has to perform the following sub-steps:

2.1. Identify the data objects to be shared.

165

166 CHAPTER 13. APPLICATION DEVELOPMENT AND REUSE

2.2. Configure the distribution of the shared data objects.

2.3. Configure the concurrency control for the shared data objects.

2.4. Couple the user interface with the shared data objects.

2.5. Replace the constructor-based creation by a registration in the runtime envi-ronment.

Usually, single-user applications are developed with respect to an applicationscheme like Arch, MVC, or PAC (see chapter 2.2.2). In this case, the data objects ofan application can easily be identified, since all these application schemes postulate aclear separation of data, application, and user interface objects. To use the identifieddata objects in a collaborative application, a developer has to change their classhierarchy, i.e. each data class has to implement the SharedObject interface anddefine the MODIFYING_METHODS field (see chapter 7).

To configure the distribution mode of a data object, a developer either has toselect one of the platform-provided evaluators or he may define his own one (seechapter 11). If a developer is not sure about which distribution mode is the best forthe data object, he can use the default mode. In this case, the runtime system usesthe user-oriented adaptive distribution scheme (see section 11.2).

To configure the concurrency control for a shared data object, a developer eitherhas to select a predefined concurrency control scheme or he may define his ownone (see chapter 6). DreamObjects offers two concurrency control schemes: anobject-based one that can be used to realize floor control mechanisms and a method-based one that achieves a maximum of concurrency. When using the object-basedconcurrency control scheme, a developer has to ensure that a site owns the floorfor a shared object, before it executes a modifying method. If a developer uses themethod-based concurrency control scheme, he has to identify the methods that mustbe executed under mutual exclusion and to check if there is a need for inter-objectconcurrency control.

In contrast to single-user applications, different users can manipulate the dataobjects of a multi-user application. To propagate the state changes of different usersto the local user interface, an application must be able to react on remote changes.For this purpose, a developer has to couple the shared data objects with the userinterface by using the notification service of DreamObjects (see section 5).

Finally, to use a shared data object in the DreamObjects environment, a devel-oper has to replace the normal constructor-based creation with the registration inthe runtime environment (see section 7.1).

In the third step, awareness services have to be added to the application. Aware-ness is an important requirement for collaborative applications. As other groupmembers are not physically present, a collaborative application has to provide somegroup feeling. This is done by so-called awareness widgets. Awareness widgets aredialog elements that offer group specific services, e.g. an overview about other users’current activities. A developer can rely on DreamTeam [Rot00a] to provide aware-ness. The runtime system of DreamTeam, e.g., offers an online list or a participant

13.1. DIAGRAM EDITOR 167

window which show all users that are currently online or work in a session. Addition-ally, DreamTeam offers awareness widgets as building blocks from its class library,e.g. distributed mouse pointers or tracking windows. Distributed mouse pointers areuseful to discuss shared documents or to point to specific items in a shared dia-gram. Tracking windows can be used to follow another one’s work if, e.g., separatescrolling of a shared document is allowed. A developer also can develop his ownwidgets. For this purpose, a widget can use information provided by the platform.The log window of the CVE, e.g., uses the notification service of DreamObjects (seechapter 5).

The three-step approach was evaluated by reusing a set of single-user applica-tions. The following sections describe some sample transformations, i.e. the trans-formation of a diagram editor, a sketch editor, a file viewer, and a spreadsheet tool.While the first example is discussed extensively, the others focus on some specialissues.

13.1 Diagram Editor

The first example is a collaborative diagram editor (see fig. 13.1), which was derivedfrom a single-user version. This diagram editor allows to construct diagrams such asflow charts or entity relationship diagrams. In contrast to a painting tool, diagramelements are not stored as bitmaps, thus a diagram can easily be modified.

Figure 13.1: A collaborative diagram editor

Fig. 13.2 shows the main classes of the single-user diagram editor and theirrelations. The DiagramEditor class is the main class of the application. It initializesthe data of the editor and contains the user interface. The user interface mainlyconsists of an icon canvas for each available diagram element and a canvas on whichthe different diagram elements can be arranged. The single-user diagram editoruses an instance of the DiagramElements class to organize its data. This instance


is accessed from the main class to either repaint the diagram or to add or removediagram elements.

Frame

DiagramElements DiagramEditor DiagramElement

DiagramCanvas DiagramIconCanvas

1 1 1 0..* 1

1 0..*

Figure 13.2: Class hierarchy of the single-user diagram editor

13.1.1 Step One

Embedding the application into the platform was simple. The main class of thesingle-user diagram editor was split in two parts: the user interface and the initial-ization of the application. Fig. 13.3 shows the resulting class hierarchy. The userinterface is now specified by the DiagramFrame class, which is almost identical tothe main class of the single-user diagram editor. The main class of the multi-user di-agram editor, i.e. DiagramEditor, was derived from the DreamObjects class library.The resulting Java class file just contains 105 lines of code.

Frame

DiagramElements DiagramEditor DiagramElement

DiagramCanvas DiagramIconCanvas

1

1 1 0..*

1

1

0..*

DiagramFrame

ObjectManagerAppl

«Schnittstelle»

ReplayableAppl

«Interface»

1

1

1

Figure 13.3: Class hierarchy of the multi-user diagram editor

The ObjectManagerAppl class demands the implementation of four differentmethods to initialize the shared data of an application (see section 12.4). Thesite that starts a session registers the container object in the createSharedData

method that is discussed later in this section. In the other cases, the containerobject just has to be bound to the application in the bindSharedData method. Thelisting in fig. 13.4 shows the bindSharedData method of the multi-user diagrameditor. Line two and three show how a developer can bind the container object tothe application. First, the object manager is accessed via the getObjectManager

method of the ObjectManagerAppl class. Then a named shared object is requested.


This means that the container object was registered with a developer-defined namethat is well-known, as it is used in the createSharedData method.

1 public void bindSharedData(){

2 elements=(DiagramElements)getObjectManager().

3 getNamedObject("elements",getReference());

4 }

Figure 13.4: Example for a bindSharedData method

Finally, to use the replay service of the latecomer support, the application classimplements the ReplayableAppl interface. For this reason, two methods as de-picted in the class hierarchy for collaborative applications (see fig. 12.7) had to beimplemented. These methods either enable the user interface elements or disablethem.

13.1.2 Step Two

The data class hierarchy of the single-user diagram editor consists of a containerobject class DiagramElements and a basic diagram element class DiagramElement,from which the different diagram elements, e.g. a rectangle or a circle, are derived.At runtime, one instance of the container class is used to keep all diagram elements.Each diagram element contains zero or more instances of the EndPoint class thatcontains the representation of an end-point.

«Schnittstelle»

SharedObject

«Interface»

+MODIFYING_METHODS

DiagramElements

+MODIFYING_METHODS

DiagramElement

+MODIFYING_METHODS

EndPoint

1 0..* 1 0..*

FourPointElement

Rectangle

Oval

Rhomb

Line

SimpleLine CornerLine

StairYLine StairXLine

EPRhomb EPCircle

EPClosedArrow EPOpenArrow

Figure 13.5: Data class hierarchy of the diagram editor

Fig. 13.5 shows the class hierarchy of the data classes after the first sub-step.Each of the basic data classes implements the SharedObject interface and de-fines the MODIFYING_METHODS field. It was not necessary to make any changesto the other data classes, as they inherit the interface implementation and theMODIFYING_METHODS field from their corresponding superclass. The listing in fig.13.6 shows the class header of the DiagramElement class.


1 public abstract class DiagramElement implements SharedObject{

2 public final static String[] MODIFYING_METHODS=

3 {

4 "resize","setColor","set1point","set2point","setFromX",

5 "setFromY","setToX","setToY","setTextFont","setLineTypes",

6 "setLineStyle","setText","setFilled","move","setOrdering"

7 };

Figure 13.6: Class header of the DiagramElement class

In the next sub-step the distribution of the data objects had to be configured.As every participating site has to access the instance of the container class to,e.g., redraw the diagram, the container object is fully replicated. The diagramelements themselves and their associated end points use the user-oriented adaptivedistribution scheme, as not every site might display the whole diagram. As describedin section 11.2.3, all adaptive distribution schemes require the implementation of asetObjectsState method that permits the runtime system to set the state of theobject. The listing in fig. 13.7 shows this method for the diagram element. Theruntime system calls this method after receiving the state of the object from acorresponding data holder. As an argument, the runtime system uses the receivedobject. Line two to ten use the passed object to set the variables of the local instance.

1 public void setObjectsState(DiagramElement de){

2 this.textFont=de.textFont;

3 this.ordering=de.ordering;

4 this.text=de.text;

5 this.lineStart=de.lineStart;

6 this.lineMiddle=de.lineMiddle;

7 this.lineEnd=de.lineEnd;

8 this.lineStyle=de.lineStyle;

9 this.filled=de.filled;

10 this.color=de.color;

11 }

Figure 13.7: Example for a setObjectsState method

To ensure the consistency of the diagram, the method-based concurrency controlscheme was used. To determine the single exclusive method sets, the modifyingmethods of the data classes were examined. The container object, e.g., just offerstwo modifying methods, i.e. a removeDiagramElement and a addDiagramElement

method, to add and remove diagram elements at runtime. These methods wereincluded in one exclusive method set EM that is also the only element of the objectexclusive method set OEM . The configuration for the end points is similar to theone of the container object, as they also offer two modifying methods.

The configuration for a diagram element is more complex, as it offers more


modifying methods. In principal, these methods can be grouped into six sets ofmethods that modify independent properties of a diagram element, i.e. the size, theline style, the color, the position, the text and the fill style. An exclusive methodset was defined for each of these method sets.

Finally, it should not be possible that a user removes a diagram element whileanother one changes some properties of the diagram element. To ensure this, theinter-object concurrency control of the container object was configured as follows.The inter-object exclusive method set IOEM for the removeDiagramElementmethodof the container object contains all modifying methods of the diagram element thatis about to be removed. The listing in fig. 13.8 shows how the sets OEM and IOEM

were implemented for the container object.

1 ObjectExclusiveMethodSet set=new ObjectExclusiveMethodSet();

2

3 ExclusiveMethodSet ems=new ExclusiveMethodSet("DiagramElements");

4 ems.addMethod("addDiagramElement");

5 ems.addMethod("removeDiagramElement");

6 set.addExclusiveMethodSet(ems);

7

8 InterObjectCCSet ioccs=new InterObjectCCSet();

9 ioccs.addIOCCMethod(new InterObjectCCMethod("DiagramElements",

10 "removeDiagramElement",

11 "removeCCRules"));

12

13 MethodCC mcc=new MethodCC(set,ioccs,null);

Figure 13.8: Example for a concurrency control configuration

In the first line, an instance of the ObjectExclusiveMethodSet class is cre-ated. This class realizes the set OEM . In the following lines, an instance of theExclusiveMethodSet class, which realizes a single EM set, is created, the modifyingmethods of the container class are added to it, and the instance is added to the in-stance of the ObjectExclusiveMethodSet class. In line eight, an instance of theInterObjectCCSet class is created. An instance of this class can be compared withthe IOEM set. In line nine an instance of the InterObjectCCMethod class is addedto this set. This instance defines that the removeCCRules method of the containerclass has to be called before the removeDiagramElement method is executed. TheremoveCCRules method defines which methods are added to the inter-object exclu-sive method set. The listing in fig. 13.9 code shows the removeCCRules method.

The removeCCRules method is called by the runtime system to determine thecontent of the inter-object exclusive method set for the remove method of the con-tainer object. As arguments, the runtime system passes all shared data objectscontained in the arguments of the removeDiagramElement method. In line two, anarray of InterObjectCCRule classes is created. An instance of this class can becompared with an exclusive method set that is contained in the inter-object exclu-sive method set. From line three to eight all shared data objects that are contained


1 public InterObjectCCRule[] removeCCRules(SharedObject[] objs){

2 InterObjectCCRule[] rules=new InterObjectCCRule[objs.length];

3 for(int i=0;i<objs.length;i++){

4 if(objs[i] instanceof DiagramElement){

5 rules[i]=new InterObjectCCRule(objs[i],

6 DiagramElement.

7 MODIFYING_METHODS);

8 }

9 return rules;

10 }

11 }

Figure 13.9: Example for an inter-object concurrency control method

in the arguments for the removeDiagramElement method are checked to determineif they are a diagram element. In this case, all modifying methods of the diagramelement are added to the corresponding instance of the InterObjectCCRule class.Thereby, it is ensured that no modifying method of the diagram element is executed,while the remove method of the container object is executed.

In the fourth sub-step the user interface was coupled with the shared data objects.The single-user diagram editor initiates a repaint of the whole diagram independentfrom the changes to the diagram. To keep the view up-to-date, the canvas of thediagram editor was registered as a call-listener for

• the instance of the DiagramElements class,

• all diagram element classes, e.g. Rectangle or Oval, and

• all end point classes, e.g. EPCircle or EPRhomb.

Thereby, the canvas is informed, whenever a displayed element changes or isadded or removed to the diagram and directly can initiate a repaint. The listing13.10 shows how the canvas was registered as a call-listener. The canvas accesses theobject manager via a method of the application. In line one the canvas is registeredas a call-listener for the container object, in line two the canvas is registered as acall-listener of all data objects that are an instance of the Rectangle class, etc.

1 appl.getObjectManager().registerCallListener(this,elements);

2 appl.getObjectManager().registerCallListener(this,"Rectangle");

3 appl.getObjectManager().registerCallListener(this,"Oval");

4 ...

Figure 13.10: Example for a call-listener registration

Finally, in the last sub-step the constructor-based creation of the data objectswas replaced with a registration in the runtime environment. The listing in fig.

13.2. SKETCH EDITOR 173

1 elements=(DiagramElements)getObjectManager().

2 registerObject("DiagramElements", // Class name

3 "elements", // Registration name

4 null, // Constructor arguments

5 mcc, // Concurrency control

6 // scheme

7 new ReplicatedEvaluator(),// Distribution scheme

8 true, // Persistency

9 getReference()); // Application reference

Figure 13.11: Example for a shared data object registration

13.11 shows the part of the createSharedData method that registers the containerobject.

In the first line the object manager is accessed via the getObjectManagermethodof the application. In the second line, the registration method of the object manageris called. The first argument declares the class name of the container class. Thesecond argument defines the registration name of the shared data object. With thisregistration name, joining sites can request the shared data object. The followingargument is set to null, as the container class does not afford any constructor argu-ments. In line five, the concurrency control scheme for the container object is passedto the registration method. The following line defines the distribution scheme of theshared data object. Line seven declares the shared data object as persistent andfinally line eight passes the application reference to the registration method.

13.1.3 Step Three

All built-in-widgets (e.g. participant windows) are available for the diagram editor.In addition, the distributed mouse pointer and the tracking window were added. Thedistributed mouse pointer is useful to point to a specific diagram element. Since adiagram can be very large, independent scrolling is allowed. To gain an overviewabout the other one’s current view, the tracking window can be opened. The costsfor integrating both elements were very low. The class, which does the paintinginside the diagram had to be derived from a DreamTeam canvas class instead ofthe standard Java canvas. In addition, some lines of code were necessary to controlthese widgets, e.g. to switch the pointers on and off.

13.2 Sketch Editor

The second example is a collaborative sketch editor (see fig. 13.12). Compared tothe previous application, the sketch editor just uses one data object to keep thesketch. This data object can be compared with a container. Whenever the useradds a line to the sketch, the coordinates of the line and its color are added to thecontainer.


Figure 13.12: A collaborative sketch editor

The transformation of the sketch editor was quite simple. In the first step, theapplication was embedded into the platform by extending the platform-providedapplication class. The createSharedData method is used to create the containerobject, when the local user initiates the application. The loadSharedData methodcalls the bindSharedData method, as in both cases the container object has to berequested from the runtime environment. As a sketch editor should have a lowresponse time, the container object was assigned a replicated distribution scheme.The two modifying methods of the container object, one for adding a line and onefor removing a line, were put in one exclusive method set to ensure the consistency ofthe sketch. The user interface was coupled to these two methods using the mapping-based notification service. Finally, to support collaboration-awareness, distributedmouse pointers were integrated into the user interface.

13.3 File Viewer

This section describes the transformation of a simple file viewer into a collaborativeone (see fig. 13.13). The single-user version allows a user to open and view a text file.In the collaborative version of this application, the user that starts the applicationcan open and view a file from his local filesystem. The other participants canremotely access the file and thus also view the file. Though this is not a verycomplex application, it is a good example for the asymmetric distribution scheme.

13.4. SPREADSHEET 175

Figure 13.13: A collaborative file viewer

The first step was quite similar to the previous applications. The second stepwas different. The single-user version uses classes, provided by Java, to initializethe access to a file, to read the content of a file, and to read the length of a file.To give all participants in a collaborative session access to the file, a shared dataobject was developed that encapsulated these services. As the user that starts theapplication is the only one that can access the file, the shared data object wasassigned an asymmetric distribution scheme. It was not necessary to configure theconcurrency control for this shared data object, as only one user is able to changethe data object, i.e. the viewed file. To keep the user interface up-to-date, themapping-based notification service was used.

13.4 Spreadsheet

The last example is a single-user spreadsheet application that is contained as anexample application in the JDK. Fig. 13.14 shows a screenshot of the collaborativeversion. The code for the spreadsheet application is publicly available, but onlysupplied with small documentation. Thus the transformation was a real challengefor the three-step approach.

Embedding the application into the runtime system was again quite simple. Thesingle-user spreadsheet application uses one data object for every cell of the spread-sheet. A little bit more effort was necessary to transform this data class. The data


Figure 13.14: A collaborative spreadsheet tool

class of the single-user application does not contain methods to set and read everyvariable, instead the application directly accesses the variables. Therefore, some ad-ditional methods had to be coded to read and write the content of the data object.As the content of a cell does not change very often, the user-oriented adaptive dis-tribution scheme was chosen. Like for the diagram element or the end points in thediagram editor, this required to implement the setObjectsState method. Finally,the user interface of the single-user application was not clearly separated from thedata of the application. However, this could be resolved with the mapping-basednotification service. In summary, the transformation could be done without consid-erable problems, though the effort for reverse engineering was higher than for theother applications.

13.5 Discussion

It is quite difficult to empirically assess the effort for the transformation of thesingle-user applications. Many factors influence the transformation process. Onthe one hand, the complexity of the application and how clean it is developed areimportant factors. On the other hand, it depends on the developer, who does thetransformation, how efficient the transformation can be done. The tables 13.1, 13.2,13.3, and 13.4 summarize the steps for transforming the applications described inthe previous sections. As a unit of measurement, the table lists the number of linesof code, which had to be written for a specific step. The effort for reverse engineeringthe original applications is not included in the table. In total, one day of work wasneeded for each application.

Reusing existing single-user applications for collaboration is an important stepto reduce development costs and increase acceptance by end-users. End-users canuse well-known applications in collaborative scenarios without having to learn new

13.5. DISCUSSION 177

Step Actions Lines of code

1: Integration Code a single class 105Code the interface for the replay service 16

2: Data Transformation of the container class 22Transformation of the diagram elementclass

34

Transformation of the end point class 8Notification service 21

3: Widgets Derive the painting class and add state-ments to control widgets

75

total 281

Table 13.1: Actions to transform the single-user diagram editor (4786 lines of code)



2: Data Transformation of the container class 5Notification service 21


20

total 157

Table 13.2: Actions to transform the single-user sketch editor (969 lines of code)


1: Integration Code a single class 842: Data Implementation of the data class 50

Notification service 103: Widgets No actions 0

total 144

Table 13.3: Actions to transform the single-user file viewer (433 lines of code)



2: Data Transformation of the cell class 30Notification service 32


46

total 241

Table 13.4: Actions to transform the single-user spreadsheet tool (997 lines of code)


ways to handle them. Since the three-step approach supports collaboration-awareapplications, group functions and awareness widgets are available.

Common applications are not based on a specific data or interface model. Plat-forms that support a specific application model either fail to support conversion orat least cause high conversion costs. The three-step approach offers the advantagesof collaboration awareness and at the same time allows to reuse existing single-userapplications.

It mainly assumes that shared data can easily be identified and be separatedfrom the rest of the application. The most critical point in the approach is toreverse engineer existing applications. If an application was developed in a ’quickand dirty’ way or the application is very complex, even with the three-step approacha successful transformation can become quite difficult.

Chapter 14

Conclusions

This chapter summarizes the main contributions of this thesis, compares them torelated work, and discusses some ideas for future work.

14.1 Summary

This thesis described a solution that simplifies the development of collaboration-aware applications by providing a set of extensible and adaptable services for datasharing. Based on an analysis of the data domain of the programmer-centered clovermodel the following main requirements were identified (see table 2.1):

• Developers must be provided with services concerning data distribution, dataconsistency, concurrency control, and data persistency (R1).

• Developers must be provided with a methodology to develop groupware appli-cations (R21).

• Developers must be able to use shared data objects transparently and mustnot be restricted during the implementation of shared data objects (R2 andR3).

• Developers must be provided with a notification service that informs interestedobjects, whenever a shared data object changes (R4 and R5).

• Developers must be able to choose between different configurable concurrencycontrol schemes and to introduce their own ones (R14-R17).

• Developers must be able to adapt the distribution of a shared data objectaccording to application-specific needs and to introduce their own distributionschemes (R6-R8).

• A set of distributed actions must transparently handle flat and nested sharedstate changes as well as accesses (R9 and R10).

• A platform-provided latecomer support must relieve the developer and mustallow latecomers to choose, if they want to join with a replay or with a directstate transfer (R12 and R13).

179

180 CHAPTER 14. CONCLUSIONS

• A decentralized persistency service must enable a transition between syn-chronous and asynchronous collaboration (R18-R20).

• A user or site that becomes unavailable must not affect the consistency andavailability of the shared state (R11).

The described DreamObjects platform offers services for data distribution, dataconsistency, concurrency control, and data persistency (R1). These services meetthe above requirements and completely relieve developers from all data sharing is-sues. DreamObjects extends DreamTeam. Like DreamTeam, DreamObjects is im-plemented in Java.

The presented three-step approach is based on DreamTeam and DreamObjects.It provides developers with a methodology on how to develop collaborative applica-tions and how to transform an existing single-user applications into a collaborativeone (R21). The example transformations show that a few hundreds lines of code areusually sufficient for a transformation. Apart from the possibility to reuse existingsingle-user applications, this approach illustrates that DreamObjects offers powerfulservices to manage shared data and that it achieves a maximum of transparency fora developer.

The transparency is achieved by the class hierarchy for the shared data ob-jects. Its basic idea is to replace a developer-defined data object at runtime with asubstitute. After an initial configuration, a developer can use the substitute like alocal data object (R2). The substitute hides the distributed actions that are neces-sary to keep a shared data object consistent. The class hierarchy does not restricta developer, when implementing shared data objects (R3). A developer can reuseexisting data classes by inheritance, as he has not to extend any platform-providedclasses. Additionally, he can feel free to compose data objects.

Application schemes for single-user as well as multi-user applications postulate aclear separation of user interface objects and data objects. DreamObjects supportsthis separation (R4) and offers a flexible notification service (R5). A developer canuse this service to couple the user interface with the shared state. To be informed,whenever a new data object is created or an existing one is removed, a developercan define and register object-listeners. To track the modifications of a shared dataobject, a developer can define and register call-listeners. Apart from the normal call-back mechanism, DreamObjects offers a mapping-based notification service. Withthe mapping-based service a developer exactly can define the information he is in-terested in and so avoids unnecessary events.

The discussion concerning the requirements for the concurrency control serviceshowed that there is no generic way for a platform to handle concurrency control.DreamObjects offers an object-based concurrency control scheme and a method-based one (R14 and R15). The offered schemes can be applied per shared object(R16). With the object-based one, a developer can implement floor control. Dueto the nature of floor control, a developer explicitly has to handle the requestingand releasing of the floor. The method-based concurrency control scheme allowsa developer to achieve a maximum of concurrency. A developer can define sets ofmethods that must be executed mutually exclusive. As DreamObjects supports

14.1. SUMMARY 181

composite data objects, there can be inter-object dependencies and these sets arenot limited to one data object. Compared to the object-based concurrency controlscheme, all necessary mechanisms are completely hidden by the substitute concept.Consequently, DreamObjects achieves further transparency. If the offered concur-rency control schemes do not meet the requirements of an application, developerscan implement and introduce their own schemes (R17).

An ideal platform has to support a variety of distribution schemes, as differentapplications or even single applications have different requirements concerning datadistribution. DreamObjects does not only support the common asymmetric andreplicated distribution scheme, it also supports two adaptive distribution schemes(R7). One of these distribution schemes adapts the distribution of a shared dataobject in relation to a user’s working style. The other distribution scheme attemptsto optimize the distribution of a shared data object with regard to the underlyingnetwork structure of the collaborating group. The supported distribution schemescan be applied on a per-object basis and first have to be defined at object registrationtime (R6). Thus, a developer can use the same object with different distributionschemes. In addition to the supported distribution schemes, DreamObjects offersan interface that enables developers to define their own distribution schemes and tointegrate them into the platform (R8).

DreamObjects supports different distributed actions to create, modify, or read avalue from a shared data object (R9). The mechanisms for the distributed actionsare either completely hidden by the substitute concept or a developer just has tocall a method of the runtime system. In both cases, he has not to care about whathas to happen.

The distributed actions respect the various distribution schemes. Instead ofinvolving all participating sites, DreamObjects just distributes messages to the sitesthat have to receive it. The distributed action for a modifying method call, e.g.,just informs the sites that either hold the data of the respective object or registereda call-listener for the method. The distributed action for a reading method call,e.g., just involves one of the sites that hold the data of the object. The distributedactions tolerate that a user leaves a session (R11). The distributed action for areading method call, e.g., sequentially tries to execute the method call as long asthere are sites left that hold the data of the object.

For a developer it is common to nest actions, i.e. to call a method of a data ob-ject in another method or to create a shared object in a method. Especially when adeveloper uses composite objects this likely happens. DreamObjects supports com-posite shared data objects and the nesting of distributed actions (R10). The nestingof distributed actions in coherence with replicated or partially-replicated objects canlead to duplicated invocations. Duplicated invocations cause unnecessary networktraffic and can lead to an unintended state of the shared objects. DreamObjectsuses a pre-filtering approach to prevent these problems.

DreamObjects supports two mechanisms to accommodate latecomers (R12 andR13). One replays how the current state was reached. As not every latecomeris interested in a replay, DreamObjects also supports a direct state transfer. Inboth cases the latecomer support is fault-tolerant, e.g. the site that supports a


latecomer can leave the session. It does not block the other participants in their workand works completely decentralized, i.e. there is no well-known site that supportsall latecomers. As the latecomer support is completely integrated in the runtimeenvironment, DreamObjects completely relieves a developer from the task to supportthe latecomer with a consistent state.

DreamObjects extends the session metaphor of DreamTeam with a persistencyservice to support transitions between synchronous and asynchronous work (R18).A developer can use this service to store and load shared data objects (R19). Aparticipant of a session can use the service to store, load, and distribute completesession states. Instead of a well-known server like in the room metaphor, it usesSMTP and NNTP. Thereby, groups that do not have access to a well-known servercan store and resume reached states (R20).

Finally, DreamObjects is based on a completely decentralized architecture, whichavoids performance bottlenecks and makes the system much more reliable. Theoffered concurrency control schemes, the distributed actions, the latecomer support,the persistency service, and the adaptive distribution schemes tolerate that a useror a site leaves a session (R11).

14.2 Comparison to Related Work

Chapter 3 described several platforms that also support the development ofcollaboration-aware applications. The presented platforms were classified accord-ing to the way how they distribute the shared state of a groupware application.

NSTP, Rendezvous, and Suite are platforms that use a central distributionscheme. All these platforms leave it to the developer to distribute state changesand thus do not achieve the required transparency (R2, R9, and R10). As theyjust offer a central distribution scheme, developers cannot choose between differentdistribution schemes or even to adapt the distribution to application-specific needs(R7-R8). Additionally, they do not fulfill the requirements concerning concurrencycontrol (R15-R17), latecomer support (R13), or data persistency (R18).

Habanero, GroupKit, COAST, DAgora, and DyCE use a replicated distributionscheme. While, in GroupKit and DyCE, developers have to identify state changeson their own (R2 and R9), Habanero, COAST, and DAgora transparently handlestate changes. Again, none of the platforms allows developers to choose betweendifferent distribution schemes or adapt the distribution (R7-R8). Additionally, noneof the platforms explicitly addresses nested state changes (R10). Only DAgoraoffers different concurrency control schemes and a persistency service that relies onmultiple servers. However, none of the platforms allows a latecomer to choose howhe wants to join a session (R13).

AMF-C, DistView, Clock, Dragonfly, Prospero, and GEN support a flexible statedistribution. Prospero leaves it to the developer to distribute state changes and thusdoes not achieve transparency (R2 and R9). DistView does not provide a notificationservice (R5). Each of these platforms allows a developer to define the distributionscheme per shared data object. Though the application scheme AMF-C supportsdifferent distribution schemes, this was only validated in the groupware platform

14.3. FUTURE WORK 183

ECooP that just supports a replicated state. The other platforms offer at least twodifferent distribution schemes. However, none of the above platforms supports anadaptive distribution scheme (R7). DistView and Clock are not extensible to furtherdistribution schemes (R8). In TCD, an implementation of the application schemeDragonfly, in Prospero, and in GEN, developers can integrate their own distribu-tion schemes, if they are completely aware of data distribution issues (R8). OnlyDistView addresses nested state changes. However, as it just supports an asym-metric and a replicated distribution scheme, it only partly fulfills the requirementR10. DistView does not support different concurrency control schemes (R15). Clocksupports different concurrency control schemes for a central distribution scheme. InProspero and GEN, developers can integrate their own concurrency control, if theyare completely aware of the underlying concepts. However, none of the platformsallows to configure concurrency control (R17). Finally, none of the platforms meetsthe requirements concerning latecomer support (R13) and data persistency (R18).

Summing up, some of the platforms fulfill a part of these requirements, but noneof them fulfills all. Some platforms support different distribution schemes and allowdevelopers to specify their own distribution schemes. Similarly, some platforms offerdifferent concurrency control schemes and allow developers to introduce their ownconcurrency control schemes. However, compared to DreamObjects, none of theplatforms

• supports an adaptive distribution scheme,

• allows developers to configure the offered distribution schemes,

• considers the effects of arbitrary distribution schemes concerning nested sharedstate changes as well as accesses,

• permits developers to configure the offered concurrency control schemes,

• allows a latecomer to choose how he wants to join a session, and

• provides a methodology on how to develop groupware applications.

14.3 Future Work

Though DreamObjects relieves a developer from all data sharing issues and achievesa maximum of transparency concerning data distribution, data consistency, concur-rency control and data persistency, there are still some open issues and ideas forfuture work.

As DreamObjects supports a variety of distribution schemes and offers an inter-face which developers can use to define their own distribution schemes, it enablesongoing research concerning data distribution for synchronous groupware. The of-fered adaptive distribution schemes use a heuristic approach. A developer can definelimits for different load values. Based on these limits, an evaluator decides, whetherit changes the distribution of a shared data object or not. As already argued, it isan application- and network-dependent task to choose appropriate limits. However,


it would be interesting to evaluate different limits for different application typesand network topologies. The results could be used to provide a developer withinstructions on how to choose the appropriate evaluator for a data object.

DreamObjects offers two mechanisms that accommodate a latecomer, one thatdirectly transfers the state and another that replays how the state was reached. Thelatter one is based on the re-execution of all modifying distributed actions. Forthis reason, the runtime system at every site maintains a history list. This historylist at least contains all modifying distributed actions that were executed by thelocal site. If a latecomer joins the session with a replay, the runtime system usesthe local history lists to construct a global one. If the group is very active or isalready collaborating for a long time, the global history list can be very large. Likein [MP95b], the history list could be extended to store snapshots of the sessionstate. Then a join with replay would start with a stored snapshot and distributedactions prior to the snapshot could be discarded. This would reduce the size of thehistory and enable a faster join with a replay. Additionally, the history list could beextended to store physical timestamps which could be used for a real-time replay.Such a replay could give a latecomer an even better feeling of how the current statewas reached.

DreamObjects assumes that participating users are not weakly connected. Cur-rently, communication technologies like UMTS and Bluetooth promise new servicesfor mobile communication. On the one hand, these communication technologies re-lieve users from accessing the Internet from a fixed place, on the other hand, thesecommunication technologies often induce a weak connection, i.e. the user is oftendisconnected. To support collaboration, even when the participants are discon-nected, DreamObjects could be extended to support object merging. Then discon-nected users could keep on working. Upon reconnection, the runtime system couldbalance the shared data objects. There already exist some systems that supportweakly connected clients, e.g. Bayou [PST+97], Coda [KS92], Rover [JTK97], orSync [MD97]. All these systems use a similar approach to merge divergent sharedobjects. First, they identify conflicting modifications. Secondly, they check, whetherthey can resolve the conflict. If they cannot resolve the conflict, they involve theusers. DreamObjects already provides an infrastructure to log modifying distributedactions. This infrastructure could be extended to also support object merging.

Currently, there exists a growing market for mobile devices such as PDAs, mobilephones, electronic pens etc. With UMTS and Bluetooth mobile devices easily canaccess the Internet. In our opinion, mobile computing provides a great potential forcollaborating users. DreamTeam was already extended to mobile platforms [Rot02].However, in the extension, called Pocket DreamTeam, a developer has to be aware ofall data sharing issues. We want to transfer the presented concepts to also simplifythe development of groupware for mobile platforms.

Bibliography

[AGW00] Gary E. Anderson, T.C. Nicholas Graham, and Timothy N. Wright. Drag-onfly: Linking Conceptual and Implementation Architectures of Mul-tiuser Interactive Systems. In Proceedings of the 22nd International Con-ference on Software Engineering, ICSE 2000, pages 252–261, Limerick,Ireland, June 2000.

[And99] Gary Eric Anderson. Dragonfly – An Implementation-Level Architecturefor Synchronous Groupware. Master’s thesis, Department of Computingand Information Science, Queen’s University, Kingston, Ontario, Canada,January 1999.

[AWF91] H. Abdel-Wahab and M. A. Feit. XTV: A Framework for Sharing XWindow Clients in Remote Synchronous Collaboration. In Proceedingsof the IEEE Conference on Communication Software: Communicationsfor Distributed Applications and Systems (TriComm ’91), pages 159–167,Chapel Hill, NC, USA, April 1991.

[BGL98] Jean-Pierre Briot, Rachid Guerraoui, and Klaus-Peter Lohr. Concur-rency and Distribution in Object-Oriented Programming. ACM Comput-ing Surveys, 30(1):291–329, September 1998.

[BGRP01] Steve Benford, Chris Greenhalgh, Tom Rodden, and James Pycook. Col-laborative Virtual Environments. Communications of the ACM, 44(7):79–85, July 2001.

[BN84] Andrew D. Birrell and Bruce Jay Nelson. Implementing Remote Proce-dure Calls. ACM Transactions on Computer Systems, 2(1):39–59, Febru-ary 1984.

[BRS99] James ”Bo” Begole, Mary Beth Rosson, and Clifford A. Shaffer. FlexibleCollaboration Transparency: Supporting Worker Independence in Repli-cated Application-Sharing Systems. ACM Transactions on Computer-Human Interaction, 6(2):95–132, June 1999.

[CCN97] Gaelle Calvary, Joelle Coutaz, and Laurence Nigay. From Single-UserArchitectural Design to PAC∗: a Generic Software Architecture Model forCSCW. In Human Factors in Computing Systems: CHI’97 ConferenceProceedings, pages 242–249, 1997.

185

186 BIBLIOGRAPHY

[CDR98] Goopeel Chung, Prasun Dewan, and Sadgopan Rajaram. Generic andComposable Latecomer Accomodation Service for Centralized SharedSystems. In S. Chatty and P. Dewan, editors, IFIP Working Confer-ence on Engineering for HCI, pages 129–145, Heraklion, Crete, Greece,1998. Kluwer Academic Publisher.

[CGJ+98] Annie Chabert, Ed Grossman, Larry Jackson, Stephen Pietrovicz, andChris Seguin. Java Object-Sharing in Habanero. Communications of theACM, 41(6):69–76, June 1998.

[Cha96] Ye-In Chang. A Simulation Study on Distributed Mutual Exclusion. Jour-nal of Parallel and Distributed Computing, 33:107–121, 1996.

[CMB+90] Terrence Crowley, Paul Milazzo, Ellie Baker, Harry Forsdick, and Ray-mond Tomlinson. MMConf: An Infrastructure for Building Shared Mul-timedia Applications. In Proceedings of the ACM 1990 Conference onComputer Supported Cooperative Work, pages 329–342, Los Angeles, Cal-ifornia, USA, October 1990.

[Coo85] Eric C. Cooper. Replicated Distributed Programs. In Proceedings of the10th ACM Symposium on Operating Systems Principles, pages 63–78,Orcas Island, Washington, USA, 1985.

[Coo86] Eric C. Cooper. Replicated Procedure Call. ACM Operating SystemsReview, 20(1):44–56, January 1986.

[DC92] Prasun Dewan and Rajiv Choudhary. A High-Level and Flexible Frame-work for Implementing Multiuser Interfaces. ACM Transactions on In-formation Systems, 10(4):345–380, October 1992.

[Dee89] S. Deering. Host Extensions for IP Multicasting. Request for Comments1112, IETF, August 1989.

[Dew90] Prasun Dewan. A Guide to Suite. Technical Report SERC-TR-60-P, Soft-ware Engineering Research Center, Purdue University, February 1990.

[Dew96] Prasun Dewan. Multiuser Architectures. In Proceedings of IFIP WG2.7Working Conference on Engineering for Human-Computer Communica-tion, pages 247–270, August 1996.

[DGLA97] Hans-Peter Dommel and J.J. Garcia-Luna-Aceves. Floor control for mul-timedia conferencing and collaboration. Multimedia Systems, 5(1):23–38,1997.

[Dou95a] Paul Dourish. Developing a Reflective Model of Collaborative Systems.ACM Transactions on Computer-Human Interaction, 2(1):40–63, March1995.

BIBLIOGRAPHY 187

[Dou95b] Paul Dourish. The Parting of the Ways: Divergence, Data Managementand Collaborative Work. In Proceedings of the Fourth European Con-ference on Computer Supported Cooperative Work, Stockholm, Sweden,September 1995.

[Dou96a] Paul Dourish. Consistency Guarantees: Exploiting Application Semanticsfor Consistency Management in Collaboration Toolkit. In Proceedings ofthe ACM 1996 Conference on Computer Supported Cooperative Work,pages 268–277, Boston, Massachusetts, USA, July 1996.

[Dou96b] Paul Dourish. Open Implementation and Flexibility in CSCW Toolkits.PhD thesis, Department of Computer Science, University College London,June 1996.

[Dou98] Paul Dourish. Using Metalevel Techniques in a Flexible Toolkit forCSCW Applications. ACM Transactions on Computer-Human Interac-tion, 5(2):109–155, June 1998.

[Edw97] W. Keith Edwards. Flexible Conflict Detection and Management In Col-laborative Applications. In Proceedings of the 10th annual ACM sympo-sium on User interface software and technology, pages 139–148, Banff,Alberta, Canada, October 1997.

[EG89] C.A. Ellis and S.J. Gibbs. Concurrency Control in Groupware Systems.In Proceedings of the 1989 ACM SIGMOD International Conference onthe Management of Data, pages 399–407, Portland, Oregon, June 1989.

[EGR91] C.A. Ellis, S.J. Gibbs, and G.L. Rein. Groupware some issues and expe-riences. Communications of the ACM, 34(1):38–58, January 1991.

[GHJV93] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. DesignPatterns: Abstraction and Reuse of Object-Oriented Design. In ECOOP’93 - Object-Oriented Programming, LNCS 0707, pages 406–431, Kaiser-slautern, Germany, July 1993. Springer-Verlag Berlin Heidelberg.

[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. DesignPatterns. Addison-Wesley, 1995.

[GM82] Hector Garcia-Molina. Elections in a Distributed Computing System.IEEE Transactions on Computers, C-31(1):48–59, January 1982.

[GM86] Hector Garcia-Molina. The Future of Data Replication. In Proceedings ofthe IEEE Symposium on Reliability in Distributed Software and DatabaseSystems, pages 13–19, Los Angeles, CA, USA, January 1986.

[GM94] Saul Greenberg and David Marwood. Real Time Groupware as a Dis-tributed System: Concurrency Control and its Effect on the Interface. InProceedings of the ACM 1994 Conference on Computer Supported Coop-erative Work, pages 207–217, Chapel Hill, NC, USA, 1994.

188 BIBLIOGRAPHY

[GMU96] T.C. Nicholas Graham, Catherine A. Morton, and Tore Urnes. Clock-Works: Visual Programming of Component-Based Software Architec-tures. Journal of Visual Languages and Computing, pages 175–196, July1996.

[GR98] Saul Greenberg and Mark Roseman. Using a Room Metaphor to EaseTransitions in Groupware. Technical Report 98/611/02, Department ofComputer Science, University of Calgary, Calgary, Alberta, Kanada, Jan-uary 1998.

[GR99] Saul Greenberg and Mark Roseman. Groupware Toolkits for SynchronousWork. In M. Beaudouin-Lafon, editor, Computer-Supported CooperativeWork (Trends in Software 7), chapter 6, pages 135–168. John Wiley &Sons Ltd., 1999.

[GS90] Bezalel Gavish and Olivia R. Liu Sheng. Dynamic File Migration inDistributed Computer Systems. Communications of the ACM, 33(2):177–189, February 1990.

[GU92] T.C. Nicholas Graham and Tore Urnes. Relational Views as a Model forAutomatic Distributed Implementation of Multi-User Applications. InProceedings of the ACM 1992 Conference on Computer Supported Coop-erative Work, pages 59–66, Toronto, Canada, November 1992.

[GU96] T.C. Nicholas Graham and Tore Urnes. Linguistic Support for the Evolu-tionary Design of Software Architectures. In Proceedings of the EighteenthInternational Conference on Software Engineering, pages 418–427, Berlin,Deutschland, March 1996.

[GUN96] T.C. Nicholas Graham, Tore Urnes, and Roy Nejabi. Efficient DistributedImplementation of Semi-Replicated Synchronous Groupware. In Proceed-ings of the 9th annual ACM symposium on User interface software andtechnology, pages 1–10, Seattle, Washington, USA, November 1996.

[GWY94] D. Garfinkel, B. Welti, and T. W. Yip. HP SharedX: A tool for real-timecollaboration. Hewlett-Packard Journal, pages 23–36, April 1994.

[Hav68] J.W. Havender. Avoiding deadlock in multitasking systems. IBM SystemsJournal, 7(2):74–84, 1968.

[HBR+94] Ralph D. Hill, Tom Brinck, Steven L. Rohall, John F. Patterson, andWayne Wilne. The Rendezvous architecture and language for construct-ing multiuser applications. ACM Transactions on Computer-Human In-teraction, 1(2):81–125, June 1994.

[Hil92] Ralph D. Hill. The Abstraction-Link-View Paradigm: Using Constraintsto connect User Interfaces to Applications. In Human Factors in Comput-ing Systems: CHI’92 Conference Proceedings, pages 335–342, Monterey,CA, USA, May 1992.

BIBLIOGRAPHY 189

[HMJ+96] Robert W. Hall, Amit Mathur, Farnam Jahanian, Atul Prakash, andCraig Rassmussen. Corona: A Communication Service for Scalable, Re-liable Group Collaboration Systems. In Proceedings of the ACM 1996Conference on Computer Supported Cooperative Work, pages 140–149,Boston, Massachusetts, USA, July 1996.

[HW93] Yixiu Huang and Ouri Wolfson. A Competitive Dynamic Data Replica-tion Algorithm. In Proceedings of the Ninth International Conference onData Engineering (ICDE9), pages 310–317, Vienna, Austria, April 1993.

[JTK97] Anthony D. Joseph, Joshua A. Tauber, and M. Frans Kaashoek. MobileComputing with the Rover Toolkit. IEEE Transactions on Computers,46(3):337–352, March 1997.

[KBL93] Alain Karsenty and Michel Beaudouin-Lafon. An Algorithm for Dis-tributed Groupware Applications. In Proceedings of the 13th Interna-tional Conference on Distributed Computing Systems, pages 195–202,Pittsburgh, Pennsylvania, May 1993.

[Kic96] Gregor Kiczales. Beyond the Black Box: Open Implementation. IEEESoftware, pages 8–11, January 1996.

[KL86] Brian Kantor and Phil Lapsley. Network News Transfer Protocol. Requestfor Comments 977, IETF, February 1986.

[KLL+97] Gregor Kiczales, John Lamping, Cristina Videira Lopes, Chris Maeda,Anurag Mendhekar, and Gail Murphy. Open Implementation DesignGuidelines. In Proceedings of the 1997 International Conference on Soft-ware Engineering (ICSE’97), pages 481–490, 1997.

[KP88] Glenn E. Krasner and Stephen T. Pope. A Cookbook for Using theModel-View-Controller User Interface Paradigm in Smalltalk-80. Journalof Object-Oriented Programming, 1(3):26–49, August 1988.

[KS92] James J. Kistler and M. Satyanarayanan. Disconnected Operation in theCoda File System. ACM Transactions on computer Systems, 10(1):3–25,February 1992.

[KS97] Lutz Kirchner and Christian Schuckmann. Groupware Developers NeedMore Than Replicated Objects. In Advance Proceedings of the Inter-national Workshop on Object Oriented Groupware Platforms - Part ofECSCW’97, pages 17–22, Lancaster, United Kingdom, 1997.

[Lam78] Leslie Lamport. Time, Clocks, and the Ordering of Events in a Dis-tributed System. Communications of the ACM, 21(7), July 1978.

[Lew98] Scott M. Lewandowski. Frameworks for Component-Based Client/ServerComputing. ACM Computing Surveys, 30(1):3–27, March 1998.

190 BIBLIOGRAPHY

[LL90] J. C. Lauwers and K. A. Lantz. Collaboration awareness in supportof collaboration transparency: requirements for the next generation ofshared window systems. In CHI ’90 Conference on Human Factors inComputing Systems, Special Issue of the SIGCHI Bulletin, pages 303–311, Seattle, Washington, USA, April 1990.

[LLSG92] Rivka Ladin, Barbabra Liskov, Liuba Shrira, and Sanjay Ghemawat. Pro-viding High Availability Using Lazy Replication. ACM Transactions onComputer Systems, 10(4):360–391, November 1992.

[LMS93] M.C. Little, D.L. McCue, and S.K. Shrivastava. Maintaining Informationabout Persistent Replicated Objects in a Distributed System. In Pro-ceedings of the 13th International Conference on Distributed ComputingSystems, pages 491–498, Pittsburgh, PA, USA, May 1993.

[LPJW96] Jang Ho Lee, Atul Prakash, Trent Jaeger, and Gwobaw Wu. Multi-User, Multi-Applet Workspaces in CBE. In Proceedings of the ACM 1996Conference on Computer Supported Cooperative Work, pages 344–353,Boston, Massachusetts, USA, July 1996.

[LR00] Stephan Lukosch and Jorg Roth. Developing Synchronous Groupware forLearning Environments. In EADTU Paris Millenium Conference, Paris,France, September 2000.

[LR01] Stephan Lukosch and Jorg Roth. Reusing Single-user Applications toCreate Multi-user Internet Applications. In Innovative Internet Comput-ing Systems (I2CS), LNCS 2060, pages 79–90, Ilmenau, Germany, June2001. Springer-Verlag Berlin Heidelberg.

[LRU99] Stephan Lukosch, Jorg Roth, and Claus Unger. Marrying On-CampusTeaching to Distance Teaching. In Proceedings of the 19th World Confer-ence on Open Learning and Distance Education, Vienna, Austria, June1999.

[LS94] M.C. Little and S.K. Shrivastava. Object Replication in Arjuna. BROAD-CAST Project Technical Report 50, University of Newcastle, October1994.

[LU99] Stephan Lukosch and Claus Unger. Flexible Synchronization of SharedGroupware Objects. ACM SIGGROUP Bulletin, 20(3):14–17, December1999.

[LU00] Stephan Lukosch and Claus Unger. Flexible Management of SharedGroupware Objects. In Proceedings of the Second International NetworkConference (INC 2000), pages 209–219, University of Plymouth, UnitedKingdom, July 2000.

BIBLIOGRAPHY 191

[Luk02] Stephan Lukosch. Adaptive and Transparent Data Distribution Supportfor Synchronous Groupware. In Jorg M. Haake and Jose A. Pino, ed-itors, Groupware: Design, Implementation, and Use, 8th InternationalWorkshop, CRIWG 2002, LNCS 2440, pages 255–274, La Serena, Chile,September 2002. Springer-Verlag Berlin Heidelberg.

[Mau00a] Martin Mauve. Consistency in Replicated Continuous Interactive Media.In Proceedings of the ACM 2000 Conference on Computer Supported Co-operative Work, pages 181–190, Philadelphia, PA, USA, December 2000.

[Mau00b] Martin Mauve. Distributed Interactive Media. PhD thesis, UniversitatMannheim, 2000.

[MD97] Jonathan P. Munson and Prasun Dewan. Sync: A Java framework forMobile Collaborative Applications. IEEE Computer, 30(6):59–66, June1997.

[MGG95a] Karim R. Mazouni, Benoıt Garbinato, and Rachid Guerraoui. BuildingReliable Client-Server Software Using Actively Replicated Objects. InProceedings of the International Conference on Technology of Object Ori-ented Languages and Systems (TOOLS), pages 37–53, Versailles, France,March 1995.

[MGG95b] Karim R. Mazouni, Benoıt Garbinato, and Rachid Guerraoui. FilteringDuplicated Invocations Using Symmetric Proxies. In Proceedings of theIEEE International Workshop on Object Orientation in Operating Sys-tems (IWOOS), Lund, Sweden, August 1995.

[MHKE01] Martin Mauve, Volker Hilt, Christoph Kuhmunch, and Wolfgang Ef-felsberg. RTP/I - Toward a Common Application Level Protocol forDistributed Interactive Media. IEEE Transactions on Multimedia, 3(1),2001.

[Mil92] David L. Mills. Network Time Protocol (Version 3) Specification, Im-plementation and Analysis. Request for Comments 1350, IETF, March1992.

[Mor94] Catherine Amy Morton. Tool Support for Component-Based Program-ming. Master’s thesis, Department of Computer Science, York University,North York, Ontario, Kanada, May 1994.

[MP94] Nelson R. Manohar and Atul Prakash. Replay be Re-execution: AParadigm for Asynchronous Collaboration via Record and Replay ofTemporal Multimedia Sessions. SIGOIS Bulletin, 15(2):32–34, Decem-ber 1994.

[MP95a] Nelson R. Manohar and Atul Prakash. Dealing with Synchronization andTiming Variability in the Playback of Session Recordings. In Proceedings

192 BIBLIOGRAPHY

of the Third ACM Multimedia Conference, pages 45–56, San Francisco,CA, USA, November 1995.

[MP95b] Nelson R. Manohar and Atul Prakash. The Session Capture and ReplayParadigm for Asynchronous Collaboration. In Proceedings of the FourthEuropean Conference on Computer Supported Cooperative Work, pages149–164, Stockholm, Sweden, September 1995.

[Mye91] Brad A. Myers. Separating Application Code from Toolkits: Eliminatingthe Spaghetti of Call-Backs. In Proceedings of the 4th annual ACM sym-posium on User interface software and technology, pages 211–220, HiltonHead, South Carolina, USA, November 1991.

[O’G96] Theodore O’Grady. Flexible Data Sharing in a Groupware Toolkit. Mas-ter’s thesis, University of Calgary, Department of Computer Science, Cal-gary, Alberta, Canada, November 1996.

[Pat91] John F. Patterson. Comparing the Programming Demands of Single-Userand Multi-User Applications. In Proceedings of the 4th annual ACM sym-posium on User interface software and technology, pages 87–94, November1991.

[Pat95] John F. Patterson. A Taxonomy of Architectures for Synchronous Group-ware Architectures. ACM SIGOIS Bulletin Special Issue: Papers of theCSCW’94 Workshops, 15(3):27–29, April 1995.

[PDK96] John F. Patterson, Mark Day, and Jakov Kucan. Notification Serversfor Synchronous Groupware. In Proceedings of the ACM 1996 Confer-ence on Computer Supported Cooperative Work, pages 122–129, Boston,Massachusetts, USA, July 1996.

[Phi98] W. Greg Philips. Dynamic Distribution for Groupware. In Proceedings ofthe CITO Innaugral Researchers’s Retreat, McMaster University, Hamil-ton Ontario, June 1998.

[PMDD00] Nuno Preguica, J. Legatheaux Martins, Henrique Domingos, and SergioDuarte. Data Management Support for Asynchronous Groupware. InProceedings of the ACM 2000 Conference on Computer Supported Coop-erative Work, Philadelphia, Pennsylvania, USA, December 2000.

[PMDS98] Nuno Preguica, J. Legatheaux Martins, Henrique J. Domingos, andJorge F. Simao. System Support for Large-Scale Collaborative Appli-cations. Technical Report TR-DI-UNL-01-98, Dep. de Informatica, FCT-UNL, Quinta da Torre, Portugal, May 1998.

[PMDS99] Nuno Preguica, J. Legatheaux Martins, Henrique Domingos, and JorgeSimao. Flexible Data Storage for Mobile Computing. In Proceedings ofthe 1999 ACM Symposium on Applied Computing, pages 405–407, 1999.

BIBLIOGRAPHY 193

[Pos81a] Jonathan B. Postel. Internet Protocol - DARPA Internet Program Pro-tocol Specification. Request for Comments 791, IETF, September 1981.

[Pos81b] Jonathan B. Postel. Transmission Control Protocol - DARPA Inter-net Program Protocol Specification. Request for Comments 793, IETF,September 1981.

[Pos82] Jonathan B. Postel. Simple Mail Transfer Protocol. Request for Com-ments 821, IETF, August 1982.

[PS94] Atul Prakash and Hyong Sop Shim. DistView: Support for Building Effi-cient Collaborative Applications using Replicated Objects. In Proceedingsof the ACM 1994 Conference on Computer Supported Cooperative Work,pages 153–164, Chapel Hill, NC, USA, 1994.

[PS95] David Plainfosse and Marc Shapiro. A Survey of Distributed GarbageCollection Techniques. In Proceedings of the International Workshop onMemory Management, Kinross, Scotland, United Kingdom, September1995.

[PS98] Frantisek Plasil and Michael Stal. An Architectural View of DistributedObjects and Components: a Unified View of CORBA, Java RMI, andCOM/DCOM. Software - Concepts & Tools, 19(1):14–28, June 1998.

[PSL99] Atul Prakash, Hyong Sop Shim, and Jang Ho Lee. Data ManagementIssues and Trade-Offs in CSCW Systems. IEEE Transactions on Knowl-edge and Data Engineering, 11(1):213–227, January 1999.

[PST+97] Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theimer,and Alan J. Demers. Flexible Update Propagation for Weakly ConsistentReplication. In Proceedings of the sixteenth ACM symposium on Operat-ing systems principles, pages 288–301, Saint Malo, France, October 1997.

[RA81] Glenn Ricart and Ashok K. Agrawala. An Optimal Algorithm for MutualExclusion in Computer Networks. Communication of the ACM, 24(1):9–17, January 1981.

[RG92] Mark Roseman and Saul Greenberg. GROUPKIT: A Groupware Toolkitfor Building Real-Time Conferencing Applications. In Proceedings of theACM 1992 Conference on Computer Supported Cooperative Work, pages43–50, Toronto, Canada, November 1992.

[RG93] Mark Roseman and Saul Greenberg. Building Flexible GroupwareThrough Open Protocols. In Proceedings of the Conference on Organi-zational Computing Systems, pages 279–288, Milpitas, California, USA,October 1993.

[RG96a] Mark Roseman and Saul Greenberg. Building Real-Time Groupwarewith GroupKit, A Groupware Toolkit. ACM Transactions on Computer-Human Interaction, 3(1):66–106, March 1996.

194 BIBLIOGRAPHY

[RG96b] Mark Roseman and Saul Greenberg. TeamRooms: Network Places forCollaboration. In Proceedings of the ACM 1996 Conference on ComputerSupported Cooperative Work, pages 325–333, Boston, Massachusetts,USA, July 1996.

[RG97a] Mark Roseman and Saul Greenberg. Building Groupware with GroupKit.In M. Harrison, editor, Tcl/Tk Tools, chapter 15, pages 535–564. O’ReillyPress, 1997.

[RG97b] Mark Roseman and Saul Greenberg. Simplifying Component Develop-ment in an Integrated Groupware Environment. In Proceedings of theACM Symposium on User Interface Software and Technology, pages 65–72, Banff, Alberta, Canada, October 1997.

[Ros95] Mark Roseman. When is an object not an object? In Proceedings of theThird Annual Tcl/Tk Workshop, pages 197–204, Toronto, Canada, July1995. Usenix Press.

[Rot99] Jorg Roth. Network Kernel Interface. http://dreamteam.fernuni-hagen.de/ dreamteam/paper/nki.pdf, October 1999.

[Rot00a] Jorg Roth. ’DreamTeam’: A Platform for Synchronous CollaborativeApplications. AI & Society, 14(1):98–119, March 2000.

[Rot00b] Jorg Roth. Entwicklungs- und Laufzeitunterstutzung fur synchroneGroupware. PhD thesis, FernUniversitat – Gesamthochschule – in Ha-gen, June 2000.

[Rot02] Jorg Roth. Mobility Support for Replicated Real-time Applications. In In-novative Internet Computing Systems (I2CS), LNCS 2346, pages 181–192,Kuhlungsborn, Germany, June 2002. Springer-Verlag Berlin Heidelberg.

[RU99] Jorg Roth and Claus Unger. Group Rendezvous in a Synchronous, Col-laborative Environment. In 11. ITG/VDE Fachtagung, Kommunikationin Verteilten Systemen (KiVS’99), March 1999.

[RU00] Jorg Roth and Claus Unger. An extensible classification model for dis-tribution architectures of synchronous groupware. In Proceedings of theFourth International Conference on the Design of Cooperative Systems(COOP2000), Sophia Antipolis, France, May 2000. IOS Press.

[SCFJ96] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobsen. RTP: A Trans-port Protocol for Real-Time Applications. Request for Comments 1889,IETF, January 1996.

[Sch90] Fred B. Schneider. Implementing Fault-Tolerant Services Using the StateMachine Approach: A Tutorial. ACM Computing Surveys, 22(4):299–319,December 1990.

BIBLIOGRAPHY 195

[Sch96] Eve M. Schooler. Conferencing and collaborative computing. MultimediaSystems, 4(5):210–225, 1996.

[SDMP97] Jorge Simao, Henrique J. Domingos, J. Legatheaux Martins, and NunoPreguica. Supporting Synchronous Groupware with Peer Object-Groups.In Proceedings of the Third USENIX Conference on Object-Oriented Tech-nologies (COOTS), Portland, Oregon, USA, June 1997.

[SE98] Chengzheng Sun and Clarence Ellis. Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements. In Proceed-ings of the ACM 1998 Conference on Computer Supported CooperativeWork, pages 139–148, Seattle, Washington, USA, November 1998.

[Sha86] Marc Shapiro. Structure and Encapsulation in Distributed Systems. InProceedings of the 6th International Conference on Distributed ComputerSystems, pages 198–204, May 1986.

[SHPJ97] Hyong Sop Shim, Robert W. Hall, Atul Prakash, and Farnam Jahanian.Providing Flexible Services for Managing Shared State in CollaborativeSystems. In Proceedings of the Fifth European Conference on ComputerSupported Cooperative Work, pages 237–252, Lancaster, United Kingdom,1997.

[Sin89] Mukesh Singhal. A Heuristically-Aided Algorithm for Mutual Exclusionin Distributed Systems. IEEE Transactions on Computers, 38(5):651–662, May 1989.

[SKSH96] Christian Schuckmann, Lutz Kirchner, Jan Schummer, and Jorg M.Haake. Designing object-oriented synchronous groupware with COAST.In Proceedings of the ACM 1996 Conference on Computer Supported Co-operative Work, pages 30–38, Boston, Massachusetts, USA, July 1996.

[SP98] Hyong Sop Shim and Atul Prakash. Tolerating Client and CommunicationFailures in Distributed Groupware Systems. In Proceedings of the 17thIEEE Symposium on Reliable Distributed Systems, pages 221–227, WestLafayette, Indiana, USA, October 1998.

[SPDM97] Jorge Simao, Nuno Preguica, Henrique Domingos, and J. LegatheauxMartins. DAgora: A Flexible, Scalable and Reliable Object-OrientedGroupware Platform. In Advance Proceedings of the International Work-shop on Object Oriented Groupware Platforms - Part of ECSCW’97,pages 27–32, Lancaster, United Kingdom, 1997.

[SSS99] Christian Schuckmann, Jan Schummer, and Peter Seitz. Modeling Col-laboration using Shared Objects. In Proceedings of the InternationalACM SIGGROUP Conference on Supporting Group Work, pages 189–198, Phoenix, Arizona, USA, November 1999.

[SUN97a] SUN Microsystems, Inc. JavaBeansTM , August 1997.

196 BIBLIOGRAPHY

[SUN97b] SUN Microsystems, Inc. JavaTM Core Reflection API and Specification,January 1997.

[SUN98] SUN Microsystems, Inc. JavaTM Object Serialization Specification,November 1998.

[SUN02] SUN Microsystems, Inc. java.sun.com - The Source for Java(TM) Tech-nology. http://java.sun.com, 2002.

[TBDP98] F. Tarpin-Bernard, B.T. David, and P. Primet. Frameworks and pat-terns for synchronous groupware: AMF-C approach. In Proceedings ofthe 7th IFIP Working Conference on Engineering for Human-ComputerInteraction, pages 225–241, Heraklion, Crete, Greece, September 1998.

[Tie01] Daniel A. Tietze. A Framework for Developing Component-based Co-operative Applications. PhD thesis, Technische Universitat Darmstadt,2001.

[TKvRB91] A.S. Tanenbaum, M.F. Kaashoek, R. van Renesse, and H. Bal. TheAmoeba Distributed Operating System-A Status Report. Computer Com-munications, 14:324–335, July/August 1991.

[TS00] Daniel A. Tietze and Ralf Steinmetz. Ein Framework zur Entwicklungkomponentenbasierter Groupware. In R. Reichwald and J. Schlichter, edi-tors, Verteiltes Arbeiten - Arbeit der Zukunft (Proceedings der FachtagungD-CSCW 2000), pages 49–62, Munich, Germany, September 2000. B. G.Teubner Stuttgart, Leipzig.

[UG99] Tore Urnes and T.C. Nicholas Graham. Flexibly Mapping SynchronousGroupware Architectures to Distributed Implementations. In Proceed-ings of Design, Specification and Implementation of Interactive Systems(DSV-IS’99), 1999.

[UIM92] The UIMS Tool Developers Workshop. A Metamodel for the RuntimeArchitecture of an Interactive System. ACM SIGCHI Bulletin, 24(1):32–37, January 1992.

[VM01] Jurgen Vogel and Martin Mauve. Consistency Control for DistributedInteractive Media. In Proceedings of the 9th ACM Multimedia, Ottawa,Canada, 2001.

[VMG+00] Jurgen Vogel, Martin Mauve, Werner Geyer, Volker Hilt, and ChristophKuhmunch. A Generic Late Join Service for Distributed Interactive Me-dia. In Proceedings of the 8th ACM Multimedia, ACM MM 2000, pages259–268, Los Angeles, CA,USA, 2000.

[WJ92a] Ouri Wolfson and Sushil Jajodia. An Algorithm for Dynamic Data Dis-tribution. In Proceedings of the 2nd Workshop on the Management ofReplicated Data (WMRD-II), Monterey, CA, USA, November 1992.

BIBLIOGRAPHY 197

[WJ92b] Ouri Wolfson and Sushil Jajodia. Distributed Algorithms for DynamicReplication of Data. In Proceedings of the ACM Symposium on Principlesof Database Systems (PODS’92), pages 149–163, San Diego, CA, USA,June 1992.

[WJH97] Ouri Wolfson, Sushil Jajodia, and Yixiu Huang. An Adaptive Data Repli-cation Algorithm. ACM Transactions on Database Systems, 22(2):255–314, June 1997.

[Woo93] Mark D. Wood. Replicated RPC Using Amoeba Closed Group Communi-cation. In Proceedings of the 13th International Conference on DistributedComputing Systems, pages 499–507, Pittburgh, PA, USA, May 1993.

[WPS+00] M. Wiesmann, F. Pedone, A. Schiper, B. Kemme, and G. Alonso. Under-standing Replication in Databases and Distributed Systems. In Proceed-ings of 20th International Conference on Distributed Computing Systems(ICDCS’2000), pages 264–274, Taipei, Taiwan, R.O.C., April 2000. IEEEComputer Society Technical Committee on Distributed Processing.

[Wri99] Timothy Nicol Wright. Hierarchical Adaptive Concurrency Control forSynchronous Groupware Applications. Master’s thesis, Department ofComputing and Information Science, Queen’s University, Kingston, On-tario, Kanada, January 1999.

[Zan01] Marion Zander. Konzeption und Realisierung eines dezentralen Algorith-mus zur Integration von Spateinsteigern in Groupware-Sitzungen. Mas-ter’s thesis, FernUniversitat – Gesamthochschule – in Hagen, September2001.

198 BIBLIOGRAPHY

Index

AActive replication, 78ALV, 15, 28, 35AMF-C, 35, 182Amoeba, 86Application, 48, 161

class hierarchy, 162reference, 48, 63, 114, 173startup mode, 163

Application reuse, 165diagram editor, 167file viewer, 174sketch editor, 173spreadsheet, 175three-step approach, 165

Arch, 15Arjuna, 35, 86Awareness, 166

distributed mouse pointer, 167online list, 166participant window, 167tracking window, 167widget, 166

BBayou, 184

CCBE, 35, 111, 122Circus, 86Clock, 36, 182ClockWorks, 36Clover, 7

programmer-centered, 7, 43, 151application functions, 7communication, 7, 43coordination, 7, 43data, 7, 12, 24, 40, 43data domain, 179

domains, 7group functions, 8user interface, 7, 43

user-centered, 7COAST, 31, 43, 111, 182Coda, 184Collaboration-awareness, 2, 27, 165Collaboration-transparency, 2, 27, 165Concurrency control

locking, 22serialization, 22

Concurrency control, 21floor control, 21social protocol, 21

Concurrency control scheme, 53, 64adaptability, 58class hierarchy, 59extensibility, 58inter-object, 54intra-object, 54method-based, 54object-based, 53

CORBA, 15Corona, 122CVE, 13, 19, 49, 52, 56, 73, 85, 167

DDAgora, 32, 43, 182Design pattern, 39

proxy, 36wrapper, 39

Distributed action, 61flat, 61follow-up, 86follow-up counter, 88, 89, 92, 93,

101, 105, 109initiating, 86method call stack, 88, 89, 93, 101,

199

200 INDEX

103, 105, 107–109modifying method call, 76, 88nested, 61, 85nesting rules, 87object deregistration, 73, 108object duplication, 70, 104object loading, 114object registration, 65, 99object storage, 112previous, 86reading method call, 81, 95

Distribution scheme, 15, 64, 139adaptive, 18, 64, 139, 140asymmetric, 15central, 15partially-replicated, 16replicated, 15static, 64, 139

DistView, 35, 43, 182dOPT, 22Dragonfly, 37, 182DreamTeam, 3, 8, 43

application, 111private mode, 111

archive manager, 10ASL, 12communication domain, 12connection manager, 10connection type, 126, 143, 144, 146coordination domain, 12data domain, 12development environment, 8FDI, 12latecomer, 122mobile platforms, 184multicast RPC, 9NKI, 11, 61, 132, 153node manager, 10pessimistic locks, 9private mode, 9public mode, 9rendezvous manager, 10runtime environment, 9session list, 10, 117session manager, 10, 116, 118

session originator, 10, 118session profile, 10, 116, 118, 131simulation environment, 11transfer manager, 10user interface domain, 12

Duplicated invocation, 85post-filtering, 85pre-filtering, 86problem, 85, 91

DyCE, 33, 182

EECooP, 35, 183Evaluator, 64, 66, 139

adaptability, 140asymmetric, 65, 139class hierarchy, 140, 141data holder, 67, 82, 98, 102, 114,

126extensibility, 140network-oriented, 65, 139, 145replicated, 65, 139user-oriented, 64, 139, 143

GGarbage collection, 74GARF, 86GEN, 39, 182GroupKit, 30, 182

HHabanero, 30, 182History list, 126

complete, 126data object, 126site, 126, 147, 148

HP SharedX, 27

IIP multicasting, 11, 58

JJAMM, 27Java, 3, 8, 151, 173

LLatecomer, 20, 121, 139

INDEX 201

direct state transfer, 20, 122, 143,145

connection phase, 125initial phase, 125

replay, 20, 133, 143, 145, 184connection phase, 134final phase, 136initial phase, 135

MMessage, 66

call-listener add, 77call-listener remove, 77constructor call, 67

follow-up, 101constructor call sent confirmation,

102data holder add, 149data holder remove, 144deregistration call, 74

follow-up, 109deregistration call sent confirma-

tion, 109duplication call, 71

follow-up, 105start permit, 106

duplication call sent confirmation,106

execution confirmation, 68, 72, 80,115

follow-up, 93, 103, 106final history request, 136final state request, 129final state support, 130, 137initial history support, 135initial history support request, 136initial object support, 127initial representation support, 126initial support request, 126, 135initial support resume, 128join complete, 131, 137load call, 114method call, 76, 82

follow-up, 89, 96, 98method call abort, 90method call result, 79, 82

follow-up, 92, 96, 99method call result sent confirma-

tion, 79follow-up, 93, 97

method call sent confirmation, 92method call start permit, 89object state request, 147object state transmit, 148registration permission, 68, 72,

103, 106, 115timestamp, 66

MMConf, 27MVC, 15, 31, 35–37

NNNTP, 119Notification service, 47

call-listener, 49, 69, 72, 78, 80, 93,103, 106, 115

event-based, 48listener configuration, 51listener interface, 49listener method, 49mapping-based, 51method call event, 50object-listener, 49, 69, 72, 75, 103,

106, 109, 115object event, 49

NSTP, 27, 182NTP, 122

OOpen implementation, 38, 39, 53ORESTE, 22

PPAC∗, 15, 35Pocket DreamTeam, 184Prospero, 38, 182

RRendezvous, 28, 182Requirements, 12, 24

concurrency control, 20data consistency, 19data distribution, 14data persistency, 23

202 INDEX

Response time, 15, 16, 27–30, 39, 58,76, 140, 142, 145, 174

Room metaphor, 9, 24, 111Rover, 184RPC, 75RTP, 122RTP/I, 122Runtime architecture, 152

application layer, 161communication layer, 153data layer, 155service layer, 157

developer services, 157system services, 157

SSession metaphor, 9, 24, 111Session state, 116

distribution, 118loading, 117storage, 116

Shared data objectdata holder, 64default constructor, 67deregistration, 73duplication, 70loading, 114merging, 184persistency, 65, 112reference, 63registration, 61registration name, 63representation, 66storage, 112write master, 79, 91–93, 96, 102,

141, 143, 144, 146, 147selection, 79, 141

Shared data object registry, 63, 69, 72,74, 75, 103, 106, 109, 115, 118,126

SMTP, 119State machine approach, 78State transmission protocol, 147Substitute, 44

generation, 62Suite, 29, 182

Sync, 184

TTCD, 38, 183TCP/IP, 11, 58, 73, 81, 154TeamRooms, 111Time space taxonomy, 1

asynchronous distributedinteraction, 1

asynchronous interaction, 1face-to-face interaction, 1synchronous distributed

interaction, 1Timewarp, 22, 122

WWeasel, 36

XXTV, 27

transparent and flexible data sharing for synchronous groupware · preface synchronous groupware...

Documents