Data management issues and trade-offs in CSCW systems

Prakash, Atul; Shim, Hyong Sop; Lee, Jang Ho

doi:10.1109/69.755630

Cited by 25 publications

(9 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…As a user interaction occurs, the server executes the application and propagates total updated application copies of states to all participants. The centralized solution is more easily implemented but as described in [3] not efficient, and since replication is more fault-tolerant [3,4] this is the solution chosen here.…”

Section: Cscw Consistencymentioning

confidence: 99%

See 1 more Smart Citation

Consistency overhead using HLA for collaborative work

Ulriksson

Ayani

2005

Ninth IEEE International Symposium on Distributed Simulation and Real-Time Applications

View full text Add to dashboard Cite

CSCW (Computer SupportedCooperative Work) has been around for many years. However, despite growing use of CSCW, general infrastructures that support it are few, and seldom provide data consistency management. A question at issue is how to easily provide different consistency policies for CSCW applications. In a modeling and simulation project at the Swedish Defense Research Agency we have evaluated technologies for developing a CSCW infrastructure. A frequently used distributed simulation architecture, the HLA, appeared as a candidate for beneficially providing CSCW services. Hence we have investigated the use of HLA for the purpose, with successful result. This paper presents some of the outcome, and the experiences from adapting an application to CSCW utilizing HLA. It presents performance experiments for evaluation of three consistency policies for CSCW using HLA, conclusions, future work and some recommendations.

show abstract

Section: Cscw Consistencymentioning

confidence: 99%

“…Consistency in CSCW deals with the problem of how to maintain data up-to-date with all users [5]. Two main approaches to consistency are centralization and replication [4]. When replicated, all clients (nodes) execute equal application replicas, and only states are distributed and coordinated among participants.…”

Section: Cscw Consistencymentioning

confidence: 99%

Consistency overhead using HLA for collaborative work

Ulriksson

Ayani

2005

Ninth IEEE International Symposium on Distributed Simulation and Real-Time Applications

View full text Add to dashboard Cite

show abstract

“…DistView is a part of the Collaboratory Builder's Environment (CBE) (Prakash et al, 1999). Normally, all shared objects are replicated.…”

Section: Related Workmentioning

confidence: 99%

Customizable Data Distribution for Synchronous Groupware

Lukosch

2004

Proceedings of the 4th International Workshop on Pattern Recognition in Information Systems

View full text Add to dashboard Cite

Abstract:The state of a groupware application must be shared to support interactions between collaborating users. There have been a lot of discussions about the best distribution scheme for the state of a groupware application. Many existing groupware platforms support only one distribution scheme, e.g. a replicated or a central scheme, and apply the selected scheme to the entire application. None of these schemes fits well for every groupware application. Different applications and even single applications have different requirements concerning data distribution. This paper describes DreamObjects, a development platform that simplifies the development of shared data objects. DreamObjects supports a variety of distribution schemes which can be applied per shared data object. Additionally, it offers an interface that developers can use to introduce their own distribution schemes.

show abstract

“…The Collaboratory Builder's Environment (CBE) [16] uses a communication infrastructure that bases on a central Corona Server [21]. This server handles the group communication, keeps a copy of the shared state, and logs all messages that are sent between the participants.…”

Section: Related Workmentioning

confidence: 99%

“…Prakash et al [16] postulate that a latecomer support has to be fault-tolerant, e.g. the site that supports a latecomer can leave the session, and it must not block the current participants of the session in their work.…”

Section: Introductionmentioning

confidence: 99%

Transparent Latecomer Support for Synchronous Groupware

Lukosch

2003

Groupware: Design, Implementation, and Use

View full text Add to dashboard Cite

Abstract. In a collaborative session users may join and leave. A user who joins a session is called a latecomer. A latecomer needs the current state of the collaborative session to participate in the session. There exist different approaches to accommodate a latecomer. The runtime system can, e.g., transfer the state to the latecomer or replay how the session state was reached. If the state is maintained on a well-known server, it is quite simple to supply the latecomer with the current state. However, if the server is not available, the latecomer cannot join. To increase the fault-tolerance, the runtime system has to use a decentralized approach. In this case, race conditions must be taken into account. DreamObjects is a platform that simplifies the development of shared data objects. It supports a direct state transfer as well as a replay and lets a latecomer choose how to join a session. Both approaches are completely integrated in the runtime system, work completely decentralized, and do not block the other participants in their current work.

show abstract

Data management issues and trade-offs in CSCW systems

Cited by 25 publications

References 27 publications

Consistency overhead using HLA for collaborative work

Consistency overhead using HLA for collaborative work

Customizable Data Distribution for Synchronous Groupware

Transparent Latecomer Support for Synchronous Groupware

Contact Info

Product

Resources

About