Integrating synchronous and asynchronous interactions in groupware applications

Transcription

1 Integrating synchronous and asynchronous interactions in groupware applications Nuno Preguiça, J. Legatheaux Martins, Henrique Domingos, and Sérgio Duarte CITI/DI, FCT, Universidade Nova de Lisboa, Quinta da Torre, 2845 Monte da Caparica, Portugal Abstract. It is common that, in a long-term asynchronous collaborative activity, groups of users engage in occasional synchronous sessions. In this paper, we analyze the requirements for supporting this common work practice in typical collaborative activities and applications. This analysis shows that, for some applications, it is necessary to rely on different data sharing techniques in synchronous and asynchronous settings. We present a data management system that allows to integrate a synchronous session in the context of a long-term asynchronous interaction, using the suitable data sharing techniques in each setting. We exemplify the use of our system with two multi-synchronous applications. 1 Introduction Groupware applications are commonly classified as synchronous or asynchronous depending on the type of interaction they support. Synchronous applications support closely-coupled interactions that allow multiple users to synchronously manipulate the shared data. During synchronous manipulation, all users are immediately notified about the updates produced by other users. At the data management level, it is necessary to maintain multiple copies of the data synchronized in realtime, merging all concurrent updates produced by the users. Several general-purpose systems have been implemented [37, 41, 39]. Asynchronous applications support loosely-coupled interactions that allow users to modify the shared data without having immediate knowledge of the modifications that are being or have been produced by other users. At the data management level, it is usually necessary to support a model of temporary divergence among multiple, simultaneous streams of activity [9] and to provide some mechanism to automatically merge these streams of activity. Some generalpurpose (e.g. [27, 10]) and application-specific (e.g. [26] for document editors) systems have been implemented. A common work practice among groups of individuals seeking a common goal is to alternate periods of closely-coupled interaction with periods of looselycoupled work. During the periods of closely-coupled interaction, individuals can This work was partially supported by FSE. 1

2 coordinate themselves and create joint contributions. These closely-coupled periods may involve all elements of the group or smaller subgroups. Between two periods of close interaction, individuals tend to work in a loosely-coupled way, by producing their individual contributions in isolation. In this paper, we address the problem of supporting this type of work practice by integrating synchronous and asynchronous support in a single platform that can be used in a mobile computing environment. To this end, we have added support for synchronous sessions in the DOORS system [33], a replicated storage system designed to support asynchronous groupware. DOORS manipulates coobjects: data objects structured according to the DOORS object framework, allowing different data-sharing strategies to be used by different applications. To support synchronous sessions, the following mechanisms have been implemented. First, it has been added support for manipulating coobjects during synchronous sessions: several replicas of a coobject can be maintained synchronized in realtime. Second, relying on the object framework, a different reconciliation technique can be used in each setting for the same coobject. This property is important for some applications (e.g. in a text editor, operational transformation can be used to in synchronous mode, and versioning can be used in asynchronous mode). Finally, we have added support to use different operations in each setting. This property is also important for some applications (e.g. in a text editor, insert/remove character operations are used in synchronous settings, and update text element/region operations are usually used in asynchronous settings). The remainder of this paper is organized as follows. Section 2 analyzes the requirements for supporting applications in synchronous and asynchronous settings. Section 3 discusses our design options. Section 4 present the DOORS system, detailing the integration of synchronous and asynchronous interactions. Section 5 presents two applications that exemplify the use of our approach. Section 6 discusses related work and section 7 concludes the paper with some final remarks. 2 Analyzing synchronous and asynchronous requirements In this section we analyze the data managements requirements of synchronous and asynchronous interactions using a set of typical groupware applications. For each application, we analyze how users use the application and what data management techniques must be used. While synchronous interactions usually last a short period of time, asynchronous interactions tend to span for very long periods. Thus, we analyze how

3 to integrate the results of a synchronous interaction in a long-term asynchronous collaborative activity. 2.1 Multi-user message/conferencing systems A conferencing system allows multiple users to communicate with each other by exchanging messages. In particular, we are interested in systems that do not restrict communication to two users. In synchronous settings, the paradigmatic conferencing application is the chat system. This type of application has evolved from very simple text-based applications, such as the chat tools available in old UNIX systems, to recent applications (e.g. ICQ, Micosoft Messengerand Yahoo Messenger) with sophisticated interfaces, advanced management tools, and integration of new features (e.g. integration with messaging systems from wireless phone networks). The basic functionality of chat systems have remained the same: to allow multiple users to send messages to a shared space that is visible to all other users 1. The only operation that a user can execute is to add a message to the shared space. The only data management requirement is to maintain, in realtime, a shared space composed by a sequence of messages. Usually, each participant maintains its own private replica of the shared space. Each new message is propagated to all participating sites using some sort of reliable group communication (either based on a centralized or on a peer-to-peer architecture). When a new message is received, it is added to the local replica usually, it is not required that all messages are added in all replicas by the same order (causal order is sufficient). In asynchronous settings, newsgroups and message boards are the paradigmatic conferencing applications. The basic functionality of this type of application is the same of the chat systems: to allow multiple users to send messages to a shared space that is visible to all other users. Regarding the data management requirements, one major difference exists: the shared space must be stored reliably for an extended period of time and even when no user is accessing the data. To this end, unlike chat systems, the data of newsgroups and message boards is usually stored in a server or group of servers that provide high data availability. Clients access these servers to read and post messages in the shared space. When the data is replicated in a group of servers, updates are usually propagated using lazy-propagation techniques [8, 20] that guarantee eventual consistency. Although synchronous and asynchronous conferencing tools have the same functionality (and it is possible to extend a message board system that uses a 1 Some chat system include other types of interactions, such as allowing an user to send a private message to another user.

4 single server to be used in a synchronous setting), users tend to use them in different ways. While messages written in a synchronous tool tend to be small, each one with a small amount of information that it is hard to understand outside of the context of a specific conversation, messages written in an asynchronous tool tend to be long and self-contained, often including transcripts of previous messages. This difference complicates the integration of a synchronous and an asynchronous conferencing tool. However, we can easily imagine scenarios where this integration could be useful: for example, a chat tool could be used to discuss some post in a message board, and the transcripts of the synchronous discussion (or a summary of the discussion) could be taken has the reply to the original post. In this case, the sequence of messages posted in the synchronous interaction should be collapsed into a single message in the asynchronous interaction. 2.2 Collaborative editing systems Collaborative editing systems allow multiple users to jointly compose and edit a shared document. In this section, we only consider structured documents composed by text: for example, a LaTeX document, an XML document or a Java source file. Many realtime collaborative editors have been implemented in the past. In older editors (e.g. DistEdit [25]), users usually took turns at making changes (all other users could only observe the changes in realtime). This approach avoids conflicts, thus greatly simplifying concurrency control. In recent synchronous editors (e.g. Grove [14], REDUCE [47]), it is common to allow multiple users to modify the shared document concurrently. In both cases, each participant maintains a copy of the shared data and all updates are propagated to all participants. In the last case, applications must also handle updates that may conflict with other concurrent updates. Operational transformation [14, 43, 2] have become the technique of choice in realtime editors because it ensures convergence while preserving causality and users intentions. This technique transforms operations to guarantee that: (1) all replicas converge to the same state despite the different execution order; and (2) the users syntactic intentions are preserved despite the fact that an operation may be executed in a state that is different from the state observed by the user that has executed the operation. For supporting collaborative edition in asynchronous settings, many systems have been implemented [32, 16, 26, 7, 5]. A common model for data access is the copy-modify-merge paradigm, in which a users gets its own private copy of the document, modify it in isolation and later his changes are merged with the mod-

5 ifications produced by other users. This approach has been implemented using either a centralized (e.g. CVS [7]) or a peer-to-peer architecture (e.g. Iris [26]). Asynchronous editing systems usually merge updates produced in different regions of the document and create multiple versions for updates that modify the same region 2. In systems that maintain the structure of the documents, the structure offers an obvious definition of a region (e.g. the leaves in documents structured as trees). In system that do not maintain the structure of the document, it is common to implicitly define a region e.g. the popular RCS algorithm [45] defines each line as a region. Even when multiple versions are created and maintained by the underlying storage system, it is usual that the document remains syntactically consistent [10], allowing users to continue accessing the document without the need to merge the multiple versions immediately (unlike the usual approach in distributed file systems [24] that prevents any normal access before solving conflicts). Although reconciliation in synchronous and asynchronous collaborative editing systems has the same goal (to automatically merge modifications produced concurrently), different techniques are used. To understand the reason for this difference, it is important to understand the limitations of each technique and how users interact to overcome such limitations in both settings. It is known that operational transformation can lead to semantic inconsistencies [44, 29]. The following example (from [44]) illustrates the problem. Suppose that a shared document contains the following text: There will be student here. In this text there is a grammatical error that can be corrected by replacing student by a student or students. If two users concurrently correct the error by executing different corrections (user 1 inserts the word a before the word student and user 2 inserts an s in the end of the word student ), operational transformation guarantees that the syntactic intentions of each user are preserved, leading to the following text: There will be a students here. However, the resulting text is semantically incorrect, as it contains a new grammatical error. Moreover, the merged version does not represent any of the users solution and it is likely that it does not satisfy any of the users. 2 Older systems (e.g. the original Lotus Notes [20]) used to retain only the most recently produced version, but this approach was considered inappropriate for asynchronous settings where large modifications are usually produced.

6 In synchronous settings, this problem can be easily solved as users immediately observe the modifications produced by other users. Thus, users can coordinate themselves and immediately agree on the preferred change. This is only possible because users have strong and fine-grain awareness information about the changes produced by other users. In this case, the automatic creation of multiple versions to solve conflicts would involve unnecessary complexity. Moreover, it is not clear what user interface widgets would be suitable for presenting these multiple versions. In asynchronous settings, updates are not immediately merged and each asynchronous contribution tends to be large. Thus, as users have no (strong) awareness information about the modifications produced by other users, it is likely that using operational transformation to merge updates produced by different users to the same semantic unit would lead to many semantic inconsistencies. This is the main reason for not using this technique in asynchronous editing systems: it seems preferable to maintain multiple versions that are semantically correct and let users merge them later (with the possible help of merging tools), instead of maintaining a single semantically incorrect version that does not satisfy anyone. There are also some technical difficulties related with the management and execution of this technique with a very large number of operations that hamper its use in asynchronous settings these problems have been partially addressed in [40]. These problems suggest that the granularity of operations used in asynchronous settings should be large for example, updating the value of some part in a structured document (e.g. a section in a paper). A system that supports synchronous and asynchronous interactions should accommodate different reconciliation techniques for synchronous and asynchronous settings. Moreover, it should handle operations with a different granularity: small, character-based, for synchronous interactions and large, regionbased, for asynchronous settings. All updates produced during a synchronous interaction can be integrated in the overall asynchronous activity as one (or a small sequence of) large-grain operation. Graphics editing Several applications for collaborative synchronous edition of graphics have been implemented [38, 31, 35, 42, 6]. Some applications use lockbased concurrency control strategies that prevent conflicts. Some recent solutions [42] propose reconciliation techniques that automatically merge updates that do not interfere with each other and create multiple versions for updates that do interfere for example, if some object (line, square, etc.) is concurrently moved to two different locations, two objects are created. In the user in-

7 terface, object versions created due to conflict are specially highlighted to allow users to differentiate these objects and solve the conflict. There are also applications that allow users to collaboratively edit graphics in asynchronous settings [15, 17]. In some of these applications [15], asynchronous interaction is limited to edit the same graphics at different times. In this case, a single stream of activity exists. In other applications [17], several streams of activity may exist leading to divergent versions of the same document. A common approach to merge the divergent streams of activity is to define one stream of activity as the master copy and replay the updates produced in all other streams in the master copy. The simplest approach is to replay updates without trying to find out if each update conflicts with other updates that have been concurrently executed in case of conflicts, this approach is similar to a last-writer wins strategy. However, as discussed in the context of collaborative edition of text documents, this approach may be inappropriate because the overwritten work may be large and important. In this case, it is not acceptable to arbitrarily discard (or overwrite) the contribution produced by some user, and the creation of multiple versions seems preferable [22]. From the above discussion, it seems that creating multiple versions in face of conflicts can be used in both synchronous and asynchronous settings. However, there are some subtle but important differences. In synchronous settings, the multiple versions are created immediately after the concurrent execution of the conflicting operations and users can observe them immediately and act accordingly for example, by solving the conflict immediately. Moreover, the number of conflicts is expected to be small as the time to propagate updates is very small (and the strong awareness information available allows users to coordinate among themselves). In asynchronous settings, as an user may produce a long sequence of updates, it is possible that a subset of these updates conflict with updates produced concurrently by other users. For example, in a diagram composed by two green squares, an user may decide to change the color of both squares to blue and another user may decide to change their color to red. In this case, although two versions of each square should be created, only two combinations of these version seem relevant: the first including the two blue squares and the second with the two red squares. Therefore, in asynchronous settings, it seems important to provide a mechanism to manage configurations composed by versions of objects [22]. This approach is unnecessarily complex for synchronous settings.

8 2.3 Group calendars Group calendars manage schedules for groups of individuals and resources. A large number of group calendars have been implemented in research projects [4, 13] and in commercial products [28, 27, 17]. The typical operations include adding a new private appointment and scheduling a group meeting or reserving a resource. For scheduling a private appointment (or reserving a resource), it is only necessary to verify that the user (resource) is free for the complete period of time. For scheduling a group meeting, it is necessary that all users can attend the meeting. To guarantee the participation of all, it is possible to simply verify that all users are available or to require an explicit confirmation from each user. Some group calendar applications allow to specify a list of alternative time periods to increase the chance of finding a compatible time period. A group calendar is a typical asynchronous groupware application, where each user can submit his operations without synchronous interaction with other users. Depending on the underlying system architecture, it may be even possible to submit operations during disconnected operation. When multiple replicas of the calendar exist, the system guarantees that all replicas converge to the same state. When it is necessary to schedule a group meeting, it may be interesting to have a synchronous session with other participants to decide the best time for example, the RTCAL application [16] provides such functionality. In the underlying group calendar, the result of a synchronous session is the scheduling of a new group meeting if appropriate, the summary of the synchronous interaction can be stored as additional meeting information. 2.4 Summary Table 1 summarizes the previous analysis focusing on two important characteristics: the granularity of update notification and the reconciliation techniques used. We also present a strategy to integrate synchronous and asynchronous interactions. In the previous subsections, we have made the case for the use of these techniques, although it is possible to use different approaches with success. This analysis allows to identify some important characteristics that must be taken into account when designing a system that supports synchronous and asynchronous interactions. First, for some applications, updates are propagated among participants using operations with a different granularity in synchronous and asynchronous

9 Conferencing system synchronous updates technical: messages social: small size reconciliation / concurrency control causal order asynchronous updates technical: messages social: large size reconciliation / concurrency control integrating synchronous updates and asynchronous reconciliation / concurrency control causal order convert sequence of small messages into a single long message Multi-user editing tool Group calendars with structured document insert/remove character decision-making tools for add/remove element to the time agreement structure add/remove appointment operational transformation for elements merge structure ops. using total order update region (e.g. section, paragraph) add/remove element for document structure versioning for elements merge structure ops. using total order compress character ops. into a single update element op. use different techniques Table 1. Analysis of synchronous and asynchronous applications. merge updates using total order alternatives for conflict resolution add/remove appointment merge updates using total order alternatives for conflict resolution use decision-making log as appointment information same technique modes. In synchronous settings, updates tend to be small and to be propagated as soon as a user executes some change to the shared data, thus allowing a tightly-coupled interaction with strong awareness of other users actions. In asynchronous settings, updates tend to be large, each one including a selfcontained contribution. For supporting both types of interaction, it seems necessary to convert sequences of small updates executed in synchronous interactions into one (or a few number of) large update for use in the long-term asynchronous interactions. Second, for some applications, different reconciliation techniques are preferred in different modes. In synchronous settings, reconciliation can be very aggressive and merge all updates in the same data version because users can immediately solve any problem that occurs. In contrast, in asynchronous settings, it is usually preferable to preserve all contributions from users, even if it is necessary to create multiple data versions, as these contributions can be long. 3 Design options In this section we present the design options used to integrate synchronous interactions in an object-based system designed to support the development of asynchronous groupware applications. In this paper we only consider issues related with data management.

10 3.1 Basic requirements and design options We start our discussion by reviewing the basic requirements that must be addressed to support synchronous or asynchronous interactions independently. Synchronous interaction In synchronous applications, users access and modify the shared data in realtime. To this end, the system must allow several applications running on different machines to maintain replicas of the shared data. When an update is executed in any replica, it must be immediately propagated to all other replicas. To achieve this requirement, our support for synchronous replication lies on top of a group-communication infrastructure, as it is usual in synchronous groupware. In this kind of support, it is important to allow latecomers to join an on-going synchronous session. We support this feature using a state-transfer mechanism integrated with the group-communication infrastructure. The user interface of the synchronous application must be updated not only when the local user updates the shared data, but also whenever any remote user executes an update. To this end, our system allows applications to register callbacks for being notified of changes in the shared data. These callbacks are used to update the GUI of the application. This approach allows a synchronous application to be implemented using the popular model-control-view pattern, with the model replicated in all participants of the synchronous session. Asynchronous interaction In asynchronous interactions, users collaborate through the access and modification of shared data. Therefore, one fundamental requirement to maximize the chance for collaboration is to allow users to access and modify the shared data without restrictions (except from access control restrictions). To provide high data availability, our system combines two main techniques. First, it replicates data in a set of servers to mask networks failures/partitions and server failures.second, it partially caches data in mobile clients to mask disconnections. High read and write availability is achieved using a read any/write any model of data access that allows any clients to modify the data independently. This optimistic approach leads to the need of handling divergent streams of activity (caused by independent concurrent updates executed by different users). Many different reconciliation techniques have been proposed in different settings (e.g. the use of undo-redo [21], versioning [7], operational transformation [14, 43, 46], searching the best solution relying on semantic information [23]) but no single technique seems appropriate for all problems. Instead, different groups of applications call for different strategies. Thus, unlike most

11 systems [13, 7, 27] that implement a single customizable strategy for reconciliation, our system allows the use of different techniques in different applications. Awareness has been identified as important for the success of collaborative activities because individual contributions may be improved by the understanding of the activities of the whole group [11, 18]. Our system includes an integrated mechanism for handling awareness information relative to the evolution of the shared data. Different strategies can be used in different applications, either relying on explicit notification, using a shared feedback approach [11], or combining both styles. Further details on the requirements and design choices for asynchronous groupware in mobile computing environments are presented elsewhere [33]. 3.2 Integrating synchronous and asynchronous interactions An asynchronous groupware activity tends to span over a long period of time. During this period, each participant can produce his contributions independently. Groups of participants can engage in synchronous interactions to produce a joint contribution. Thus, it seems natural to consider the result of a synchronous interaction as a contribution in the context of the long-term collaborative process. We have used this approach in our object-based system. In the following subsections, we address specific requirements for implementing this strategy. Updates with a different granularity As discussed in the previous section, in some applications, updates are propagated between replicas using operations with a different granularity for synchronous and asynchronous interactions. To address this problem, our system includes a mechanism to compress the log of operations submitted by users. During a synchronous interaction, the small operations executed by users are incrementally converted and compressed in a small sequence of large operations. This sequence of large operations is the result of the synchronous session and it is integrated in the asynchronous collaborative process as any contribution produced by a single user. The same mechanism is used to compress the updates produced by a single user. Different reconciliation techniques As discussed in the previous section, in some applications, it is interesting to use different reconciliation techniques in different setting to handle updates executed concurrently. To address this problem, we structure data objects used in collaborative applications according to an object framework that includes independent components to handle most aspects

12 related with data sharing, including reconciliation and awareness management. Thus, when a programmer creates a data type to be used in a collaborative application, she can specify different reconciliation techniques to be used in synchronous and asynchronous settings. The same approach can be used for handling awareness information in different ways during synchronous and asynchronous interactions. In our system, when an operation is executed it is possible to generate specific awareness information that is processed by a component of the data object. For example, in a shared document, it may be interesting to maintain a log of modification produced over time. This log can be updated by the awareness component used in asynchronous settings. In synchronous settings, the needed awareness information is usually provided by the applications as the result of updates to the shared data. Therefore, this additional awareness information can be discarded. 4 DOORS In this section, we present the DOORS system. We start by briefly presenting the system architecture and the object framework. A more detailed description of these elements of the system, and how they can be used to support only asynchronous groupware can be found in [34]. Then, we detail the mechanisms used for integrating synchronous sessions in the overall asynchronous activity. 4.1 Architecture DOORS is a distributed object store based on a extended client/replicated server architecture. It manages coobjects: objects structured according to the DOORS object framework. A coobject represents a data type designed to be shared by multiple users, such as a structured document or a shared calendar. A coobject is designed as a cluster of sub-objects, each one representing part of the complete data type (e.g. a structured document can be composed by one subobject that maintains the structure of the document and one sub-object for each element of the structure). Each sub-object may still represent a complex data structure and it may be implemented as an arbitrary composition of common objects. Besides the cluster of sub-objects, a coobject contains several components that manage the operational aspects of data sharing figure 1 depicts the approach (we describe each component and how they work together later). Sets of related coobjects are grouped in volumes that represent collaborative workspaces and store the data associated with some workgroup and/or collaborative project.

13 Application Attributes sub-object proxies Adaptation Log Concurrency control Capsule Cluster manager sub-objects Awareness System Fig. 1. DOORS object framework. The DOORS architecture is composed by servers and clients, as depicted in figure 2. Servers replicate volumes of coobjects to mask network failures/partitions and server failures. Server replicas are synchronized during pairwise epidemic synchronization sessions. Clients partially cache key coobjects to allow users to continue their work while disconnected. A partial copy of a coobject includes only a subset of the sub-objects (and the operational components needed to instantiate the coobject). Clients can obtain partial replicas directly from a server or from other clients. Applications run on client machines and use a get/modify locally/put changes model of data access. First, the application obtains a private copy of the coobject (from the DOORS client). Second, the application invokes subobjects methods to query and modify its state (as it would do with common objects). The update operations are transparently logged (and compressed) in the coobject. Finally, if the user chooses to save her changes, the logged sequence of operations is (asynchronously) propagated to a server epidemic propagation updates sub-objects updates sub-objects sub-objects & updates sync sessions Key Server Client Sub-objects Application Fig. 2. DOORS architecture composed by four computers with different configurations. Coobjects are replicated by servers, partially cached by clients and manipulated by users applications.

14 When a server receives operations from a client, it delivers the operations to the local replica of the coobject. It is up to the coobject replica to store and process these operations. Coobject replicas are synchronized during epidemic synchronization sessions. During these sessions, servers propagate sets of operations between coobjects replicas. As described, DOORS is fully built around the notion of operation-based update propagation. The system core only executes the minimal services that represent the common aspects of data management (to propagate sequences of updates and to maintain the client cache). DOORS delegates on the coobjects most of the aspects related with the management of data sharing, such as concurrency control and the handling of awareness information. The rationale behind this design is to allow the implementation of flexible type-specific solutions. 4.2 DOORS object framework The outlined design imposes a heavy burden on coobjects, which must handle several aspects that are usually managed by the system. To alleviate programmers from much of this burden and to allow the reuse of good solutions in multiple data types, we have defined an object framework that decomposes a coobject in several components that handle different operational aspects (see figure 1). In this subsection we outline the complete object framework, introducing each component in the context of the local execution of an update operation. Each coobject is composed by a set of sub-objects that may reference each other using sub-object proxies. These sub-objects store the internal state and define the operations of the implemented data-type. The cluster manager is responsible to manage the sub-objects that belong to the coobject, including: the instantiation of sub-objects (when needed); and the control of sub-objects persistency (e.g. using garbage-collection). Applications always manipulate coobjects data through sub-objects proxies. When an application invokes a method on a sub-object proxy, the proxy encodes the method invocation (into a simple object that includes information to trace its causal dependencies and to order them) and hands it over to the adaptation component. The adaptation component is responsible for interactions with remote replicas. The most common adaptation component executes operations locally. But other implementations are available, allowing to execute operations in a server or to change the execution location depending on the connectivity. Local execution is controlled by the capsule component. Query operations are executed immediately in the respective sub-object and the result is returned to the application. Update operations are logged in the log component. When-

15 ever an operation is logged, the capsule calls the concurrency control component to execute it. The concurrency control/reconciliation component is responsible to execute the operations stored in the log. In the client, operations are usually executed immediately. The result of this execution is tentative (showing the expected result) [13], as an update only affects the official state of a coobject when it is finally executed in the servers. To guarantee that all (server) replicas evolve in a consistent way and that users intentions are respected, different concurrency control/reconciliation components implementing different strategies may be used in the server (this problem is discussed extensively in [33]). During the execution of the operations some awareness information may be produced. This information is handed over to the awareness component that immediately processes it (storing it to be later presented in applications and/or propagating it to the users using the systems notification services). Besides controlling the local execution of operations, the capsule component defines the coobject s composition and aggregates its components. The composition described in this subsection represents a common coobject, but it is possible to define different compositions for example, it is possible to maintain a tentative and a committed version of the sub-objects using two different reconciliation components to execute updates stored in a single log using an optimistic and a pessimistic total order strategy respectively. The capsule component also defines the interface with the system for exposing the logged operations and processing the operations received during epidemic synchronization sessions. Finally, the attributes component stores the system and type-specific properties of the coobject. To create a new data-type (coobject) the programmer must do the following. First, he must define the sub-objects that will store the data state and define the operations (object methods) to query and to change the state. From the sub-objects code, a pre-processor generates the code of sub-object proxies and factories to be used to create new sub-objects, handling the tedious details automatically. Second, the programmer must define the coobject composition selecting the adequate pre-defined components (or defining new ones if necessary). Different components can be specified for use in the server and in the client during private and shared (synchronous) access. As these components encode most of the data-sharing semantics, different data-sharing approaches can be obtained using different pre-defined components.

16 4.3 Integration of synchronous sessions In this subsection we detail the integration of synchronous sessions in the overall asynchronous activity. Manipulate coobjects in synchronous sessions: As we have seen in section 2, each site that participates in a synchronous section usually maintains its own copy of the shared data. To this end, we need to maintain several copies of a coobject synchronously synchronized. To achieve this goal, we use an adaptation component (called synchronous adaptation component) that propagates updates executed in any replica to all replicas that participate in the synchronous session. This component relies on a group communication sub-system for managing communications among participants of the synchronous (GCSS) session (two different implementations exist, one relying on JGroups [1] and other relying on the Deeds event-dissemination system [12]). An application (user) may start a synchronous session in a client when it loads a coobject from the data storage. In this case, the coobject is instantiated with the components specified for shared access in the client 3. In particular, the adaptation component must be a version of the synchronous adaptation component. This component creates a new group (in the GCSS) for the synchronous session. When a new user wants to join a synchronous session, the user s application has to join the group for the synchronous session (using the name of the session and the name of one computer that participates in the session). During the entrance process, the application receives the current state of the coobject (including all instantiated sub-objects) from a designated primary in the group (relying on the state transfer mechanism of the GCSS). A private copy of the coobject is created (instantiated) using the received state. Any user is allowed to leave the synchronous session at any moment. In DOORS, the sub-objects are only instantiated by the cluster manager when they are accessed. When a coobject is being manipulated in a synchronous session, the initial state of a sub-object is obtained from the designated primary 3 It is also possible to start a synchronous session using a private copy of a coobject that is being modified. In this case, the system starts by replacing the components used for private access by the components used for shared access (when they are different). The new components are initialized with the state of the old components. To this end, we have defined an interface to export and import the relevant state of components in a generic way. If some used component does not implement this interface, it is only possible to start a synchronous session with a freshly loaded cooobject.

17 in the group to guarantee that all replicas instantiate all sub-objects in a coherent way 4. Application Attributes 9 Adaptation Log Concurrency control 8 7 Cluster manager Awareness Application Attributes 9 Adaptation Log Concurrency control 8 7 Cluster manager Awareness Capsule Capsule 2 Group communication system Application Attributes 9 1 Adaptation 3 Log 6 Concurrency control Capsule Cluster manager 8 Awareness Fig. 3. Synchronous processing of an update operation in three replicas of a coobject. Applications manipulate coobjects as usual, i.e., by executing operations in sub-objects proxies. The proxy encodes the operation and delivers it to the adaptation component for processing. Query operations are processed locally as usual (see details in section 4.2). For an update operation, the adaptation component propagates the operation to all elements of the synchronous session, as depicted in step 2 of figure 3. The GCSS delivers all operations in the same order in all replicas. When the operation is received in (the adaptation component of) a replica, including the replica where the operation has been initially executed, its execution proceeds as usual (by handing the operation to the capsule for local execution, as explained in section 4.2). Using this approach, it is very simple to maintain all replicas consistent: as all update operations are received in all replicas in the same order, the concurrency control component just has to execute all operations in the order they are received 5. 4 Whenever a replica needs to instantiate a sub-object, it sends a request to the group. The primary replies to this request by sending the initial state of the sub-object (as obtained from the DOORS client) to all replicas all replicas cache the initial state of the sub-object for future use. 5 Note that even using this approach it is possible to preserve users intentions executing operational transformation techniques before executing an update.

18 An alternative approach has also been implemented: the operation is propagated using a FIFO order (only guaranteeing per-sender ordering). This order guarantees that the operation is delivered immediately in the local replica, thus imposing no delay on local execution of operations (local execution proceeds as usual). In this case, as operations are delivered in different orders in different replicas, it is usually necessary to rely on operational transformation to guarantee that all replicas remain consistent. To update the application GUI, an application may register callbacks in the adaptation component to be notified when sub-objects are modified due to operations executed by remote users (or local users). These callbacks are called by the adaptation component when the execution of an operation ends (step 9). The DOORS approach to manage synchronous interactions, described in this subsection, does not imply any contact with the servers. An application running on a DOORS client can participate in a synchronous session if it can communicate with other participants using the underlying GCSS. Thus, a group of mobile clients, disconnected from all servers, may engage in a synchronous interaction even when they are connected using an ad hoc wireless network. Saving the result of a synchronous interaction as an asynchronous contribution: As discussed in section 3.1, for some applications, it is necessary to convert the small operations used during synchronous interaction into the large operations used for asynchronous interaction. Compress (seqops: list, newop: operation) = FOR i:= seqops.size - 1 TO 0 DO IF Compress( seqops, i, newop) THEN RETURN seqops ELSE IF NOT Commute( seqops.get(i), newop) THEN BREAK END FOR seqops.add( ConvertToLarge( newop)) RETURN seqops Fig. 4. Algorithm used for log-compression. In the DOORS system, this is achieved by the log compression mechanism implemented by the log component. As described in section 4.2, all update operations executed in a synchronous session are stored in the log before being applied to the local replicas of the sub-objects. Besides the full sequence of operations, the log component also maintains a compressed version of this sequence. An operation is added to the compressed sequence just before being

19 stably executed (and after the reconciliation component executes the last undo or transformation to the operation) using the algorithm presented in figure 4. The basic idea of the algorithm is to find out an operation already in the log that can compress the new operation (e.g. an insert/remove operation in a text element can be integrated into an operation that sets a new value to the text element by changing the value of the text). If no such operation exists, the new operation is converted into an asynchronous operation and added to the sequence of operations in the log (e.g. an insert/remove operation in a text element can be converted into an operation that sets a new value the current value of the text modified by the operation to the text element). To use this approach it is necessary to define the following methods used in the compression algorithm: Compress, for merging two operations; Commute, for testing if the result of executing two operations does not depend on the execution order; ConvertToLarge, for converting a small synchronous operation into a large asynchronous operations this operation has access to the current state of the coobject. The examples presented in the next section show that these methods are usually simple to write. The result of the synchronous session is the compressed sequence of operations stored in the log. Only the designated primary can save the result of the session. In respect to the overall evolution of the coobject, the compressed sequence of operations that is the result of the synchronous sessions is handled in the same way as the updates executed asynchronously by a single user. Thus, the sequence of executed operations is propagated to the servers, where it is integrated according to the reconciliation policy that the coobject uses in the server. Using different reconciliation strategies: As discussed in section 3.1, for some applications, it is important to use different reconciliation techniques during synchronous and asynchronous interactions. In the DOORS system, it is possible to use different techniques by specifying that a coobject is composed by different components in the server and during shared access in the client. The reconciliation component used during shared access in the client controls how updates are applied to each replica maintained by the participants of the synchronous session. Thus, this component defines the reconciliation strategy for synchronous interaction. The reconciliation component used in the server controls how updates are applied to the stable replicas maintained by the servers. Thus, this component defines the reconciliation strategy for asynchronous interactions. A similar approach is used for the awareness component, allowing to use different approaches to handle information created during synchronous and asynchronous interactions.

20 5 Applications In this section, we present two applications that exemplify our approach to integrate synchronous and asynchronous interactions. These applications have been implemented in Java 2. The DOORS prototype has also been implemented in Java 2 (the pre-processor is implemented using JavaCC). 5.1 Multi-synchronous document editor The multi-synchronous document editor allows users to produce structured documents collaboratively these documents are represented as coobjects. A document is a hierarchical composition of two types of elements: containers and leaves. Containers are sequences of other containers and/or leaves. The complete structure of a document, including all containers, is stored in a single subobject. Leaves represent atomic units of data that may have multiple versions and that may be of different types. Each leaf is represented by a sub-object. For example, a LaTeX document has a root container that may contain a sequence of text leaves and/or scope containers. A scope container may also contain a sequence of text leaves and/or scope containers. There is no direct association between these elements and LaTeX commands/elements. Users are expected to use scope elements to encapsulate the document structure. For example, a paper can be represented as a sequence of scope elements, each one containing a different section (see figure 5). The file to be processed by LaTeX is generated by serializing the document structure - all text is contained in text leaves. structure (modified elements in red) nmp updates versions jalm updates chat & sync. session members Fig. 5. Multi-synchronous document editor with a LaTeX document, while synchronously editing one section.