Combining Asynchronous and Synchronous Collaborative. Institut fur Informatik, Technische Universitat Munchen, Postfach , D{8000 Munchen 2,

Transcription

1 Combining Asynchronous and Synchronous Collaborative Systems Gunnar Teege and Uwe M. Borgho Institut fur Informatik, Technische Universitat Munchen, Postfach , D{8000 Munchen 2, Germany. fteege,borghoginformatik.tumuenchen.de Abstract There are a variety of dierent CSCW applications for group collaboration. Among others, systems for asynchronous coordination as well as synchronous multiuser ors are current research topics. Each system has its advantages. Thus, combining the advantages of such systems should be even more advantageous. We have developed a new objectoriented, asynchronous activity support system, called TACTS, and a new synchronous multiuser or, called IRIS. We explain how both systems can be combined using the underlying state models, and show the advantages of the combination. 1. INTRODUCTION Transparent access to shared information is the main goal of distributed le systems, distributed operating systems, and distributed database systems. In collaborative systems, however, full transparency and a strict isolation of users are contraproductive. Therefore, CSCW systems try to weaken the concept of transparency and to introduce the concept of collaborationaware group interaction. There a variety of CSCWapplications. Among systems for group decision support, desktop conferencing, and electronic meeting rooms, there are systems for coordination as well as multiuser ors. The latter systems, the asynchronous coordination approaches as well as the synchronous collaborative ing approaches are often implemented as standalone applications. Smooth transitions should be supported between using technology and conventional methods of writing, between individual work and group work, between planning, outlining, writing, and annotating the document, and between synchronous and asynchronous work by group members [1]. The combination and integration of such applications providing smooth transitions should be advantageous. A characteristic dierence between synchronous and asynchronous collaborative systems is the use of shared data. A pure asynchronous system is looselycoupled and does not involve shared data. We will concentrate on this dierence and show how to systematically integrate a system with private data and a system with shared data. The main idea will be to use data states to model the former, and work group states to model the latter system, and to combine these models into a common one. We describe the concrete application to two systems supporting collaborative work on documents, both developed in our department. The rst one is the new objectoriented, asynchronous activity coordination system TACTS, the second is the new synchronous multiuser or IRIS. Sects. 2 and 3 briey describe the design concepts of TACTS and IRIS, respectively. In Sect. 4, we explain how both approaches can be smoothly combined and how this combination will benet from the interrelation. Finally, Sect. 5 concludes by discussing the lessons learned.

2 2. TACTS In this section we describe the rst collaborative system used for the combination. It is the asynchronous activity support system TACTS that primarily supports the structuring, execution and history of activities of a single user. The system supports activities in a way similar to the Coordinator [4], and supports oce procedure plans as does the Domino System []. However, the combination with IRIS only concerns the class of activities which represent work on a document. Among others, TACTS supports ing, transformation, printing and the sending of documents by electronic mail. A full description of the objectoriented structure of TACTS and of all types of supported objects is out of the scope of this overview. Interested readers are referred to [8]. For every document all activities concerning the document (together with the document content, if stored electronically) are represented by a TACTS object. This kind of object uses a general TACTS mechanism to maintain an explicit state. The possible states and transitions together form a nite state automaton. The state automaton is the main user interface for document objects. The user may select and activate any transition which is dened for the current state of the object. All document objects in TACTS use a common automaton with four states, namely \", \", \xed", and \in " as shown in Fig. 1. The states may be interpreted as to describe the state of the document content. We call these states document content states. The document content comprises the data which is private for TACTS and must become shared in the combination of TACTS and IRIS. Thus the automaton describes the relevant behavior in respect to the data and will be used for the combination. The semantical description of the document content states is as follows. In brackets the rst export doc export doc appearance of the appropriate transition is indicated. In state \ " the document content does import doc not or an ing document has been init doc x doc deleted (erase doc). In state \" the document content s due to initialization xed erase doc (init doc) or due to import from an external source, e.g., (import doc). Export start doc stop doc activities leave this document content state unchanged (export doc). Exporting means processing the content in some way, e.g., printing it or sending it with to another user. All collaboration with respect in to documents in TACTS is done by importing and exporting (parts of) the document TACTS' Automaton for Document Objects. Fig. 1: contents. (The collaboration partners are modeled by explicit \agent" objects.) In state \in " the ing document is under manipulation, i.e., the user has started an ing session (start doc). When the ing session is left, the document returns to state \" (stop doc). In state \xed" the ing document has been nally xed, i.e., the current version has been frozen and cannot be ed any more (x doc). Export activities leave this document content state unchanged. Aside from the state, a document object maintains other specications such as time which uses a general time mechanism provided by TACTS. Every document object records the time of every export to a specic goal, the last time interval in which the document was not in state \", and all time intervals the document was in state \" or \xed". The latter intervals dene the document versions.

3 3. IRIS In this section we briey describe the synchronous collaborative system IRIS used for the combination. It is a newly developed multiuser or for multimedia documents. Like CES [5] and MultimETH [7], IRIS allows for structural changes without harm to the content information. Both content and structural information of a document are fully replicated. In order to achieve pessimistic concurrency control and to avoid inconsistencies, even when dierent users are working on the same parts of a document at the same time, IRIS uses a distributed replication control scheme based on dynamic voting [2]. More details are given elsewhere [3]. The group ing the document is formed implicitly by the act of opening a le to. Working with IRIS can be seen as using the following automaton with four states, namely \", \", \", and \" as shown in Fig. 2. We call these states work group states. The semantical description of the work group states is as follows: In state \ " the group of users sub user stop user working with IRIS does not. In state \" the group of users working with IRIS s due to a rst addition add user of an IRIS user () or due to the sub user stopping of the ing by some user of the group (stop user). Further additions or some removals of users from the user group (sub user) leave this work Fig. 2: IRIS' Automaton for Synchronous Collaborative Work. group state unchanged, provided there is at least one user remaining in the user group. In state \" the last user has been removed from the user group (). Finally in state \", one of the user has started ing the document (). Further starts (add user) or quits (sub user) of users ing the document leave this work group state unchanged as long as at least one user continues to the document. 4. COMBINING BOTH SYSTEMS As we have seen, TACTS as well as IRIS are nice standalone systems with specic advantages. Thus, we try to combine the advantages of both systems into an integrated CSCWsystem. The goal of the attempt is to have true synchronized access to a document while retaining all additional TACTS operations on documents (aside from ing). The main solution is to use IRIS for storing, accessing and ing of the document contents and structure and to make the necessary parts of IRIS accessible from TACTS for the implementation of other operations. This involves adapting the dierent models for, e.g., structuring and versioning used in both systems. As our main step we show how the state automata for the document content and the work group, respectively, can be combined. Afterwards we discuss one of the advantages of the resulting combination, namely the enhanced way of navigating through the version tree. Combining the State Automata: As a rst step we augment the automaton used explicitly by TACTS. We choose a systematic approach to do so by combining it with the automaton modeling the use of IRIS. While TACTS is mainly concerned with the state of the document content, the main concern of IRIS is the state of the group working on the document. By combining these approaches we can integrate both views. We construct an intermediate automaton as follows. Combined states are all pairs \X/Y" with X being a work group state in the IRIS

4 automaton and Y being a document content state in the TACTS automaton. This results in 1 combined states. Every transition from X 1 to X 2 in the IRIS automaton now is dened for all \X 1 // / /Y" with arbitrary Y and leads to \X 2 // /Y". This results in four copies of every IRIS transition in the intermediate automaton. The TACTS transitions are handled analogously, i.e., IRIS transitions are printed in the horizontal columns whereas TACTS transitions are printed in the vertical rows. For better readability, moreover, we write all IRIS work group states and their corresponding transitions in italic. /// stop user // / / erase doc erase doc erase stop user... doc erase doc import/init doc import/init doc import/init doc import/init doc / start/stop doc start/stop doc start/stop doc start/stop doc in in in in.... stop user... R xed xed. xed xed... stop user x doc x doc x doc x doc / / / / Fig. 3. Intermediate Document Automaton for Synchronous Activities. Semantically, the intermediate automaton, as depicted by Fig. 3, describes all resulting states which can be described by a combination of the work group states and the document content states. For reasons of simplicity, we do not include transitions where the source and target states are identical. In the given intermediate document automaton for synchronous activities, however, not all combinations are useful. Thus we modify the intermediate automaton based upon semantic considerations. There are three states in which the work group is undened, whereas the document content is dened, namely \/" \/in ", and \/xed". Semantically, only the work group can manipulate the content; thus these states are meaningless. We remove them together with all corresponding transitions. When the work group is nally, the document content can no longer be changed. We model this by removing the states \/in " and \/". The former state can only be reached from the latter state via a transition start doc. The latter state can be reached in two ways: From state \/" via transitions init doc or import doc, respectively, and from state \/" via transition.

5 When the work group is, init doc and import doc are semantically impossible and can be removed. The transition in state \/" can be handled by following it automatically with the transition x doc, thus ending in state \/xed". Semantically this is correct: Whenever the last member leaves the work group, the document content is automatically xed and can no longer be changed. In Fig. 3 this is expressed by the thick arrow from state \/" to state \/xed". The corresponding transition can be labelled with sublast user x doc where \" respresents the concatenation of two transitions. Explicit xing no longer makes sense, since it can only be issued by a single group member. This does not guarantee that other members may not wish to change the document content. Thus, we delete the transitions x doc in the states \/" and \/". This makes the states \/xed" and \/xed" unreachable, so they are removed as well. Semantically, the document content is ed whenever at least one group member is ing it. We handle this by integrating the two states \/" and \/in " into the state \/in ". Thus, all transitions starting or ending in one of the two states now start or end in \/in ", respectively, and the other two states are removed. The transitions start doc and are combined into a single transition because they imply each other. The same holds true for stop doc and stop user. This is indicated by the special symbol \k". sub user The result of the discussed modications is illustrated in Fig. 4. The export doc export doc... IRIS transitions are marked with dotted lines. The semantical interpretation of the combined states is ob import doc.. tained by simply combining the semantics of the individual states given init doc in Sects. 2. and 3., respectively. The erase doc automaton shows the smooth integration of all TACTS operations with start doc k stop doc k sub user x doc xed all IRIS operations. It is still possible to export and import the con stop user. tent asynchronously, as in TACTS, and to it synchronously, as in in IRIS. The main change in the implementation of the TACTS operations.. export doc add user is the use of IRIS for storing the document content. Note however that sub user Fig. 4: the state combination has introduced Automaton for TACTS/IRIS documents. an export doc transition at state \/in ". For its implementation the version of the contents to be exported must be specied. A possible solution would be to export the last valid version previous to the current ing session. Combining the Version Mechanisms: As a second step we show how the dierent version mechanisms can be combined and of what benet this is to IRIS. To keep versions in IRIS manageable to the user, every version is given attributes, such as the time of its ence or the name of the user responsible for the new version. The interface that gives access to older versions of the document allows associative access to versions via its attributes (such as selecting the last version created by the user himself) as well as stepping through the version tree. In TACTS, the history of a document is a nonbranching linear list of versions encapsulated in a single object. Therefore, TACTS must create a new object whenever the IRIS version tree branches.

6 TACTS itself provides additional attributes, e.g., protocoling the export activities. A user can select a document version by simply classifying it as, for instance, the last version he printed. The combination of TACTS and IRIS allows for the selection of a version in the following way: Depict the last, the second last, etc., version that was printed, mailed, etc., by a third person. These are advantages IRIS has not to \pay" for. They are byproducts of its combination with TACTS. 5. CONCLUSION IRIS is implemented in ANSIC and runs on our HPworkstation cluster operating HPUX V8.07. The ISIS toolkit V3.0 is used to provide the multicast feature. The graphical interface has been written using the InterViews 3.01 software package. TACTS is implemented on top of the proprietary EmacsLispObjectOrientedSystem ELIOOS which has been specially developed for TACTS. It has full access to all ing, mailing and other communication mechanisms available in GNU Emacs. It uses the or's own multiwindow interface together with the mouse support available under the X Window System to communicate with the user. As we have shown, it is possible to combine conceptually dierent systems in a systematic way, i.e., in the given example, the asynchronous activity support system TACTS using private data and the synchronous distributed multiuser or IRIS using shared data. In our approach we modeled the main behavior of the individual systems with the help of state automata and combined these into a model for the behavior of the combined system. After considering the specic state semantics we reduced the model accordingly. The result fully integrated the operations of both systems. A similar approach should be possible whenever the system behavior can be modeled by a state automaton. The lessons learned are that the additional overhead for combining both systems is relatively small, due to the systematic approach. It is by far outweighed by the advantage of having the features of both systems integrated into a single system, e.g., the additional ways of selecting dierent versions of a document. We are grateful to Anke Makio and Michael Koch for implementing the rst version of IRIS, and to Hans Schmid for implementing the time mechanism of TACTS.. REFERENCES 1. Baecker, R.M.: New Paradigms for Computing in the Nineties. Proc. of Graphics Interface, Los Altos, CA: Morgan Kaufmann Publ. Inc., pp. 224{ Borgho, U.M.: Fehlertoleranz in verteilten Dateisystemen: Eine Ubersicht uber den heutigen Entwicklungsstand bei den Votierungsverfahren. InformatikSpektrum 14:1, 15{27 (Feb. 1991) 3. Borgho, U.M., Teege, G.: Application of Collaborative Editing to SoftwareEngineering Projects. ACM SIGSOFT Software Engineering Notes 18:3, A{5{4 (Jul. 1993) 4. Flores, F., Graves, M., Harteld, B., Winograd, T.: Computer Systems and the Design of Organizational Interaction. ACM Transactions on Oce Information Systems :2, 153{172 (Apr. 1988) 5. Greif, I., Seliger, R., Weihl, W.: Atomic Data Abstractions in a Distributed Collaborative Editing System (Extended Abstract). Proc. 13th ACM SIGACT/SIGPLAN Annual Symp. on Principles of Programming Languages, St. Petersburg Beach, FL, Jan New York: ACM, pp. 10{172. Kreifelts, T., Hinrichs, E., Klein, K.H., Seuert, P., Woetzel, G.: Experiences with the DOMINO oce procedure system. In: Bannon, L., Robinson, M., Schmidt, K. (eds.): Proc. 2nd Europ. Conf. on Computer Supported Cooperative Work, Amsterdam, The Netherlands, Sep Dordrecht, Boston, London: Kluwer Academic Publ., pp. 117{ Lubich, H., Plattner, B.: A Proposed Model and Functionality Denition for a Collaborative Editing and Conferencing System. In: Gibbs, S., VerrijnStuart, A.A. (eds.): Proc. IFIP Conf. WG 8.4 Conf. on Multi User Interfaces and Applications, Heraklion, Greece, Sep Amsterdam, New York: NorthHolland, pp. 215{ Teege, G.: The Activity Support System TACTS. Inst. fur Informatik, Techn. Univ. Munchen, Munich, Germany, Technical Report TUM{I 930, Apr. 1993