In order to provide clean separation of semantics and presentations, interactive software applications and infrastructures commonly use some variant of the Model- View-Controller (MVC) paradigm illustrated on the left side of Figure 1.6. In this
Figure 1.6: The Model-View-Controller (MVC) Paradigm.
figure, circles represent software components, arrows represent method calls or events, and squares represent the product of views (projections). In this paradigm the model M maintains semantic state and behavior, the view V maintains a projection of the model, and the controller C transforms user inputs applied to the projection into op- erations on the model. The pseudo-code of Figure 1.7 sketches an MVC organization of the application of Figure 1.4. Because the view and controller are intimately tied to the user interface (projection) and to each other, and because interactions (bind- ings of keyboard and mouse events to operations on a model) are rarely customized separately from the view, controller functions are often subsumed by the view as demonstrated by the right side of Figure 1.6 and the pseudo-code of Figure 1.8. The primary advantage of MVC is that it separates models and views so that they can be
Figure 1.7: Spreadsheet MVC Organization
reused with other views (Figure 1.9) and models (Figure 1.10), respectively.
Figure 1.9: Reused Model
Two important variants of the MVC paradigm are pull (Figure 1.11) and push
(Figure 1.12) MVC2. In the pull variant the view pulls data from the model, while in the push variant the model pushes data to the view. The pull variant is the classical MVC paradigm proposed in [KP88] and utilized by Smalltalk. The model need know nothing about the view except that it is interested in changes in the model. The view needs to know more about the model in order to query it for its current state, but it can be reused with other models supporting the same interface. Figure 1.7 has been fleshed out as Figure 1.13 to demonstrate pull MVC.
The push variant is more efficient than the pull variant because the model only notifies a view of changes in the particular aspects of the model in which the view is interested, and because the model sends descriptions of the changes with the notifi- cation. The trade-off is that this requires more knowledge of the view by the model. 2Pull and push MVC are described in more depth in the Observer design pattern[GHJV95a], which will be introduced shortly.
Figure 1.10: Reused View
Figure 1.12: Push MVC
That is, the model must have more specific information about the view’s interests, and it must match model changes to these interests. To demonstrate the push vari- ant, we need a slightly more elaborate application with specific interest specifications by views. Figure 1.14 sketches an example application where the model is a list of stocks and their current quotes, while the view selectively displays stock symbols and quotes. Note that the model only notifies views that have expressed an interest in the particular stock whose quote has changed. Interests can be more complex than this example demonstrates. For example, a view might only want to be notified when stock S reaches a quote of at least Q. Note that in a pull implementation of this application the model would notify all views when any stock changes, and each view would have to pull the quotes of all stocks in its interest set to determine which, if any, had changed, and whether the change was significant to the view.
the Observerdesign pattern[GHJV95a]. Adesign pattern is a generic object-oriented solution to a software engineering problem that shows up in many contexts3. The
Observer design pattern uses the terms Subject for Model and Observer for View, where the observer can be any object interested in the subject’s state changes, not just view user interface elements. The Observer design pattern may be cascaded to produce multiple layers, as shown in Figure 1.15. The middle object in this diagram has two roles: it is an observer of the subject above and a subject for the observer below. Cascading can continue indefinitely, but is subject to per-layer performance overhead.
Figure 1.15: Cascading the Observer Design Pattern to Produce Layers
1.6
Centralized and Replicated Architectures
MVC and the Observer design pattern are applicable to a wide range of software systems, whether individual or collaborative, colocated or distributed, synchronous or asynchronous. Synchronous distributed collaboration obviously requires distribu- tion of software and hardware components and data among multiple sites. Such 3MVC is also a design pattern. See [GHJV95b] for a complete discussion of these and other design patterns.
distributed systems require architects to make decisions about how components and computations are to be distributed.
Synchronous distributed collaborative systems have historically been categorized as having either centralized or replicated architectures. Different definitions of cen- tralized vs. replicated architectures are used in the literature. (See, for example, [Dew99] and [GR99].) I will create and use the following definitions. My definitions generalize upon the definitions in [GR99], which are specified at a coarse application level of abstraction.
A centralized architecture (Figure 1.16) is one where each aspect of se- mantic state and its behavior is represented at any given time by exactly one master model.
Consider, for example, the application of Figure 1.16. All stocks could be represented by one model as shown, each stock could be represented by a separate model, or any- thing in-between. A given stock or all stocks could shift from one model instantiation to another. However, a given stock cannot be simultaneously represented by more than one model. There may be slave models corresponding to each master model (e.g., transparent observer/subjects used to increase performance or fault tolerance), but these are restricted to precisely tracking the master model’s external state and its transitions.
By contrast,
Areplicatedarchitecture (Figure 1.17) is one where each aspect of semantic state and its behavior is represented simultaneously by multiple (peer) master models. These models are synchronized in some fashion but are not required to go through the same sequence of external state transitions. That is, Model 0uModel 1uModel 2 in Figure 1.17. All three models represent the same stocks, stock LEH is the same in all three models, the quotes are all the same,
and the values are all Shares times Quotes. However, the number of shares of the
TEXstock differs among all three models and the number of shares ofGGGin Model 2 differs from the number of shares in the other models. The fact that a given stock can simultaneously have multiple static semantics exposes the fact that a replicated architecture is being used; that is, that a given real thing is being represented by multiple models simultaneously.
Both centralized and replicated synchronous distributed collaborative systems have been built, each class having its characteristic advantages and disadvantages. Centralized systems support simpler user mental models and are easier to implement, but they suffer from greater latency and reduced scalability. Replicated systems im- prove latency and scalability at the cost of more complex user mental models and implementations.
To understand these trade-offs, consider again Figures 1.16 and 1.17. The user’s mental model of the application as implemented by the centralized system of Fig- ure 1.16 is simple, because he and his collaborators always see consistent, though perhaps different, projections of the model (ignoring different transmission times that will cause users’ displays to be updated at slightly different times). Even considering network transmission times, all projections go through states corresponding to exactly the same sequence of model transitions. By contrast, users of the replicated system of Figure 1.17 must construct a more complex mental model of the application, because their projections need not conform to each other at any particular point in time, and the sequence of updates to one user’s projection need not be consistent with the sequence of updates to another user’s projection. Figures 1.18 and 1.19 demonstrate these problems. In Figure 1.18, the users may become confused because some out of band communication mechanism (e.g., audio or video) exposes the inconsistencies in model values. Furthermore, if each user changes the number of shares in his local
model copy as indicated by the shaded boxes of Figure 1.17, and the models are ulti- mately synchronized, the sequence of model (and therefore projection) changes may be inconsistent from user to user, as shown in Figures 1.19 and 1.20. Note that each
Figure 1.19: Model Synchronization in a Replicated System
participant starts and ends with the same projection, but the intervening projection sequences differ. (For clarity, I have given each user the same pie-chart projection and have only shown the pies themselves in Figure 1.20.) Whether or not these update sequence differences are of any consequence depends on the application. The point here is that the separate models change in ways that are inconsistent with viewing them as a virtual representation of a single shared real thing. Finally, it should be apparent that replicated systems are more difficult to implement, since they, unlike centralized systems, require synchronization of models.
Figure 1.20: Differing Projection Sequences Caused By Replicated Model Synchro- nization
tive performance than centralized systems. There are three reasons for this:
• The impact of network latencies on interactive performance is much greater for centralized systems. For example, if network transmission time is 100ms, as shown in the centralized system of Figure 1.21, every user interaction (e.g., every incremental movement of the cards being dragged in the figure) will have a latency (i.e., the time between the user’s movement of the mouse and the corresponding movement of the cards) of at least 200ms. In a replicated system, the user dragging the cards would get immediate feedback.
• In a centralized system, the “center” of the system where the model resides can become overloaded if many participants join a collaborative session. In a replicated system this will not happen, because there is no unique “center” that must process all interactions. Thus, replicated systems are more scalable in terms of the computations that must be performed.
• A centralized system typically places more demands on network bandwidth than a replicated system, because lower-level operations are transmitted over the network (e.g., mouse movements instead of final card positions). Thus, like the processor at the center, the network is more likely to become overloaded. This, like the former point, means that replicated systems generally scale better than centralized ones.
The focus of this work is on scenarios involving highly synchronized collaboration, where multiple simultaneous participants react to other participants’ actions on vir- tual things by invoking their own actions, all during a short (e.g., sub-second) time span. Examples are users working together closely on a game, a puzzle, or a project. Conceptually, the simpler user mental models supported by centralized architectures are better suited to these scenarios than the more complex mental models required by replicated architectures. The whole point of highly synchronous collaboration is to share some virtual thing at the current point in time. This implies that the model defining the real thing should be unique. In replicated architectures the approxima- tions in the equation Model 0 u Model 1 u Model 2 can cause confusion for users, particularly if there are out-of-band communication channels that can redundantly communicate model state, as we saw in Figure 1.18. Replicated architectures are used where performance is at a premium and can be purchased at the cost of complexity for implementors and participants.