18
execution history, while many revision control systems allow multiple versions and branch-
ing execution histories, even though they are implemented by a central repository.
The extent and visibility of data replication is an important architectural difference
among collaboration systems. Decisions about data replication exert pressure on the forms of
collaboration that will be permitted, since the data replication architecture will make some
operations easier and some harder. Furthermore, the performance and availability character-
istics of some architectures affect the kind of user support that can effectively be offered.
At one extreme are systems that replicate no data. Such a system can use several possible
architectures. A server-based system is relatively simple to implement, and can provide any
form of consistency-guarantee that is desired, but it also implies some severe practical limi-
tations. A server-based approach only works when the network is reliably available most of
the time, since all synchronization operations must use the network to access the server.
Network delays can affect the interactivity of the response, as can the concentrated work-
load of all users, if the transaction rate is high.
Many object-oriented data distribution strategies use some form of object migration or
remote procedure call, so that object identity is never compromised by the creation of repli-
cas. Objects must be moved across the network, on-demand, to be updated, or a remote call
must be forwarded to whatever CPU the object resides on. This is the most transparent model
for an application programmer, since the underlying object system manages all the
concurrency details automatically. This approach, however, has many of the same drawbacks
as the client/server architecture when used as a method of collaboration support, since po-
tential write conflicts on the same object are relatively likely in collaborative editing. Dis-
connected operation is also particularly difficult, as relatively fine-grained object models
may be hard to partition for disconnected operations. While object replicas can be used to
provide read-only access to unavailable objects, the need for application awareness of
concurrency issues and divergent states resurfaces.
execution history, while many revision control systems allow multiple versions and branch-
ing execution histories, even though they are implemented by a central repository.
The extent and visibility of data replication is an important architectural difference
among collaboration systems. Decisions about data replication exert pressure on the forms of
collaboration that will be permitted, since the data replication architecture will make some
operations easier and some harder. Furthermore, the performance and availability character-
istics of some architectures affect the kind of user support that can effectively be offered.
At one extreme are systems that replicate no data. Such a system can use several possible
architectures. A server-based system is relatively simple to implement, and can provide any
form of consistency-guarantee that is desired, but it also implies some severe practical limi-
tations. A server-based approach only works when the network is reliably available most of
the time, since all synchronization operations must use the network to access the server.
Network delays can affect the interactivity of the response, as can the concentrated work-
load of all users, if the transaction rate is high.
Many object-oriented data distribution strategies use some form of object migration or
remote procedure call, so that object identity is never compromised by the creation of repli-
cas. Objects must be moved across the network, on-demand, to be updated, or a remote call
must be forwarded to whatever CPU the object resides on. This is the most transparent model
for an application programmer, since the underlying object system manages all the
concurrency details automatically. This approach, however, has many of the same drawbacks
as the client/server architecture when used as a method of collaboration support, since po-
tential write conflicts on the same object are relatively likely in collaborative editing. Dis-
connected operation is also particularly difficult, as relatively fine-grained object models
may be hard to partition for disconnected operations. While object replicas can be used to
provide read-only access to unavailable objects, the need for application awareness of
concurrency issues and divergent states resurfaces.
