CAIP-TR-264
Maintaining State Consistency Across Heterogeneous Collaborative Applications Ivan Marsic*, Xiaodong Sun†, Carlos Correa*, and Tongyin Liu‡ * †
Department of Electrical and Computer Engineering and the CAIP Center
Department of Mathematics, ‡Rutgers Center for Operations Research (RUTCOR) Rutgers University, Piscataway, NJ 08854
{marsic, cdcorrea}@ece.rutgers.edu,
[email protected],
[email protected]
March 2002
Maintaining State Consistency Across Heterogeneous Collaborative Applications Ivan Marsic*, Xiaodong Sun†, Carlos Correa*, and Tongyin Liu‡ * †
Department of Electrical and Computer Engineering and the CAIP Center
Department of Mathematics, ‡Rutgers Center for Operations Research (RUTCOR) Rutgers University, Piscataway, NJ 08854
{marsic, cdcorrea}@ece.rutgers.edu,
[email protected],
[email protected]
Abstract—The proliferation of computer devices and wireless networks allows the users to access information and collaborate with others from anywhere, using the device that best matches the current context. Device capabilities constrain the application implementation, which implies that the user interface and the shared information will differ across devices. Some shared information may be omitted or abstracted to fit the device capabilities and, as a result, the application state differs on different devices. Therefore, there arises a problem of consistency management of the application state across different platforms. Application state is determined by the data structures that represent the application’s data and its user interface and we assume that the application state can be represented as a graph data structure. We present a set of conditions on the rules relating the states in different implementations of an application and derive an algorithm which maintains the state consistency under the user interactions. We also illustrate an application scenario that benefits from heterogeneous state representations.
Index Terms—Consistency management, heterogeneous computing, graph isomorphism.
1
1 INTRODUCTION Computing platforms are rapidly becoming more heterogeneous, primarily in terms of device capabilities. The major differences arise in CPU speeds, memory, display characteristics, and network connectivity. Small portable devices, such as handheld computers, smart phones and pagers, are becoming popular means to access the Internet. Traditional application frameworks have concentrated on systems of similar machines. However, with heterogeneous devices proliferating, there is a need for applications that are tailored to the capabilities of their current computing and communications environment. Such tailoring results in different data representations, GUI structures and behaviors on different platforms. There have been heterogeneous platforms and applications in the past, but what is new is ubiquitous connectivity that allows them to access and share the same data and collaborate at the same time. Our work concerns the interoperation of these applications so that the users can equitably and efficiently employ heterogeneous computer devices. Some typical scenarios for using diverse platforms include teams collaborating on shared data or pervasive computing where the application state is available anywhere, so the user at different times employs different devices to access and edit the same document. We believe that in both scenarios the users are mainly interested in data. The user wants to share data, whether synchronously with collaborators or asynchronously alone from a different platform. Consequently, the problem of interoperating device-tailored applications is reduced to the problem of managing consistency of the data structures (application state) across different devices. It is important to point out that each client runs a full application and maintains application state, since a key requirement is that the system 2
supports disconnected operation. Wireless links often provide only intermittent connectivity, so it is desirable to maintain a local state to enable the user to continue the work while disconnected, and to re-synchronize when the client gets opportunity to reconnect. The application state consists of all application’s data structures that are relevant for the process of sharing. An example of application state is what in two-dimensional and three-dimensional graphics applications is usually called scene graph. It is a hierarchical description of scene objects, with scene objects, their parts and parts of their parts represented at different levels of abstraction. Other examples include conceptual knowledge representation using relationships such as inheritance, spatial or temporal proximity, etc. There are different data structures and in this work we focus on the graph data structure as a canonical representation, since it is the most general one and the results can be relatively easily generalized to other data structures. Some typical application scenarios are illustrated in Fig. 1. In the first scenario, the application’s user interface is described in a markup language and mapped to device-specific software objects that implement the generic interface components. In the second scenario, the shared data are mapped into different representations that best match the device capabilities, e.g., 3D vs. 2D spatial data representations. Both scenarios could be considered as collaborative applications: in the first case the user asynchronously “collaborates” with himself/herself, while in the second case the user synchronously collaborates with other users. Thus in the rest of text we refer to only collaborative applications.
3
User 1 on Platform 1 at Time t1
map_u1_p1 map_u1
User 1 GUI Description
Abstract GUI Description map_un
map_u1_pm
…
… Platform m, User 1 GUI Description
User 2 GUI Description
Server
Platform 1, User 1 GUI Description
User 1 on Platform m at Time t2 ≠ t1
(a)
map_p1 Shared Document
Platform 1, Shared Document
map_pm
… Server
User 1 on Platform 1
Platform m, Shared Document User n on Platform m
(b)
Fig. 1. Example applications for heterogeneous platforms. (a) The user employs at different times the same application on different platforms. Abstract description of the application’s GUI is mapped to the particular platform the user currently works on. (b) Collaborators concurrently access and edit a shared document from different platforms. The mappings are in both cases bi-directional to support sharing. A key issue in interactive information sharing is maintaining consistent state across the
applications running at distributed sites. This is required in order to have meaningful collaboration; otherwise the application states at different sites would diverge, in which case they could as well be considered as entirely disconnected from each other. Consistency means logical equivalency among the replicated copies of the same data object. Maintaining consistent state of 4
replicated clients in homogeneous systems is a well-researched problem, see e.g., [1,5,16], and is not addressed here. However, in addition to the problems inherited from homogeneous collaborative applications, there are some problems specific to heterogeneous applications and the latter are the main focus of the paper.
1.1 Objectives of This Work Suppose that two remote sites run an application tailored to the site’s computer platform. As the users interact with the applications, the application state transitions must be consistent so to provide meaningful collaboration. The following diagram represents the problem. Let us assume that the application states at the two sites are consistent at a time t. The mapping between them is denoted as “map1.”
[ site1 state (t ) ] map1 → [ site2 state (t ) ] ↓ op1
↓ op2
[ site1 state (t + 1)] map2 → [site2 state (t + 1)] At the time t+1, the user interacts with the application at site 1 (“op1”) and it transitions to a new state. To maintain consistency, site 2 must also transition to a new state which is consistent with that of site 1. We could either apply an operation “op2” to the old state of site 2 or a mapping “map2” to the new state of site 1. We assume that it is always more efficient in terms of network traffic to compute “op2” at site 1 and send it to site 2, rather than to compute the new state of site 2 using “map2” and then transmit the entire new state to site 2. This may not always be true, but the solution can easily be generalized. If the platforms were homogeneous, the operations “op1” and “op2” would be identical and could
be
directly
distributed across
the collaborative applications. Due to platform5
specific differences, “op1” first needs to be transformed to adjust to different domains. The transformation of state operations to the corresponding local application domains allows their interoperation. This paper is not concerned with how the mapping “map1” is determined, i.e., we are not concerned with defining and/or checking semantic consistency. For this we would need to run human factors investigation to determine the rules for tailoring the data representation to fit platform capabilities. The set of rules generates “map1” mappings and needs to be checked for consistency. Instead of defining semantic consistency, this paper is only concerned with maintaining it. We derive an algorithm which guarantees that the state consistency will be maintained assuming that the rules are consistent. Given the mapping “map1” and the operation “op1”, the algorithm derives the mapping “map2” or the operation
“op2” such that the
application states remain consistent as they transition in response to users interactions. The paper is organized as follows. We first review the state of knowledge and related work. Next, Section 2 defines the state consistency for heterogeneous distributed applications and derives an algorithm that preserves the state consistency. This model only deals with the topological structure of the application-state graph. Section 3 extends the model to graphs with vertices with property lists. Section 4 reports on implementation and an application scenario. Finally, we conclude the paper and outline future research directions.
1.2 Related Work
To our best knowledge, there has been no other work on consistency in collaborative applications with heterogeneous data representations. Heterogeneous groupware was considered
6
in [9], but even though the system runs on different computing platforms, the platform capabilities are assumed to be sufficiently similar to support essentially the same application on all platforms. Dewan and Sharma [4] focus on interoperating group systems with different policies (concurrency control, coupling) and architectures (centralized vs. replicated), but do not consider the semantic consistency issues arising from computing device heterogeneities. In our system, the semantics of data representations and exchanged messages is different across the domains to accommodate platform heterogeneities. Interactive applications are often developed using the Model-View-Controller (MVC) design pattern to achieve reusable components and flexible human-computer interfaces [7]. The model corresponds to the application state. Several researchers proposed MVC separation in synchronous groupware, with either centralized or distributed models and polymorphic views rendered on distributed hosts. Some groupware systems implement the distributed MVC pattern, e.g., [13], but only a simple version where the model is centralized and the views are distributed. Some researchers remark on the possibility of a fully distributed MVC, e.g., [14], but do not report implementing such. XWeb [12] defines interactive framework for diverse computing devices and it in a way implements a distributed MVC, where each client maintains the state information. However, the mapping between the application states of different sites is assumed to be one-to-one which effectively results in a system with homogeneous application states. Work on interoperating databases, e.g., [15], concerns itself with mapping queries so the data can be accessed from heterogeneous databases. Due to the assumption that all domains have exact (i.e., one-to-one) correspondence, this work is of limited applicability here. Consistency
management
is
important
in 7
multiperspective
specifications,
such
as
multiperspective software [6], document [11], and distributed system [2] specifications. The representation styles of various perspectives can be highly heterogeneous and open-ended since those perspectives should be presented in a form appropriate to each participant in the development process. A key problem is detecting and resolving inconsistencies between the different representations. The work presented here is complementary in the sense that it deals with maintaining consistency between different representations. Recent work on Web browsing from different devices, e.g., [8], considers one-way distribution of web pages to diverse devices. There is no need for maintaining consistency since the flow of information is one-way.
2 TOPOLOGICAL STRUCTURE CONSISTENCY In this section we solve the problem of maintaining consistency as follows. First, without a loss of generality, we consider a configuration with one client and one server. We use graphs to represent the application state at the client and server sites and at first only consider the topological structure of the graphs. Then we present three conditions on the relations between these graphs. Based on the conditions, we decompose the problem into three special cases which can be considered individually. Finally, we present an algorithm that maintains state consistency under these three cases. It is sufficient to consider the simple case with one server and one client since the results easily extend to the case of multiple clients and servers. We assume that the server maintains the complete application state as a graph Gs. Because Gs contains all the information, we call it 8
super-graph. The application state on the client, denoted as a graph Gc, is typically less detailed, and it never contains more information than Gs. The results can be generalized to peer-to-peer scenarios, where the peer with the most detailed representation is equivalent to the server. The application developer is required to define the rules for deriving a graph Gc from a graph Gs. The developer’s objective is to customize the application to best match each platform and he or she best knows the application semantics and the specific platform customizations. Let ℜ denote the set of rules for generating a graph Gc given a graph Gs. These rules can be expressed, for example, using eXtensible Stylesheet Language (XSL) [17]. For a given graph G, let V(G) denote the vertex set, E(G) the edge set, and P(G) the path set (including the edges, which are paths of length 1). We require that every pair (Gs, Gc) generated by ℜ satisfy the following conditions: (A1) There is a subset V* of the vertex set V(Gs), such that there is a surjective mapping Mv : V* → V(Gc). (A2) There is a subset P* of the path set P(Gs), such that there is a surjective mapping Mp : P* → E(Gc). If v1 and v2 are the end vertices of a path p∈P* then Mv(v1) and Mv(v2) are the end vertices of the edge Mp(p). (A3) For each path p∈P*, the internal vertices of p are not in V*. Paths in P* do not intersect. No two paths in P* share the same pair of end vertices. There may be other relationships between general graphs, but these conditions capture the types of the applications we are interested in. These applications obtain a client graph Gc by applying techniques such as data compression, abstraction, summarization, and level-of-detail control. 9
Remark 1. The reason we have paths in Gs to correspond to edges in Gc is that sometimes we
omit the intermediate vertices but still want to maintain the connection between the two ends. It is like flattening a parts hierarchy of an object by removing the intermediary vertices. For the third condition, if two paths intersect we may include the intersection vertex in Gc so that the condition is satisfied. Based on the conditions, we have the following proposition. Proposition 1. Given that the relation between Gs and Gc complies with the above conditions,
any mapping from Gs to Gc is a composition of the following three types of mappings: (i)
Isomorphism from a subgraph Gs* of Gs to Gc.
(ii)
Isomorphism from Gs' to Gc where Gs' is obtained by merging a path in Gs, where all internal vertices have degree 2, to an edge.
(iii) Isomorphism from Gs' to Gc where Gs' is obtained by contracting a subset of vertices in the Gs to a single vertex. Proof. We construct graphs Gs' and Gs'', such that the mapping from Gs to Gc is decomposed into
a type (i) mapping from Gs to Gs', a composition of type (ii) mappings from Gs' to Gs'', and a composition of type (iii) mappings from Gs'' to Gc. This is illustrated in Fig. 2. Let V*⊆V(Gs) and P*⊆P(Gs) be the subsets defined in the conditions (A1) and (A2) above. First, let Gs' be the minimum subgraph of Gs that contains both V* and P*. Notice that the vertices of Gs' are those in V* and the internal vertices of paths in P*. Let V*(Gs') ⊆V(Gs') denote the set of vertices in V(Gs') that are in V* and P*(Gs') ⊆P(Gs') denote the set of vertices in P(Gs') that are in
10
( Mv , Mp )
Gs
Gs'≅ Gs*, a subgraph of Gs.
Gs'
Gc
Gc is obtained by contracting vertex sets in Gs''
1 Gs'' is obtained by merging paths in Gs'
3
Gs''
2
Fig. 2. Decomposition of the mapping from Gs to Gc.
P*. Let Mv' denote the isomorphism from V* to V*(Gs') and Mp' the isomorphism from P* to P*(Gs'). Notice (Mv', Mp') is a type (i) mapping. Now let Gs'' be the graph obtained from Gs' by merging paths in P*(Gs') of length more than 2. Due to the condition (A3), these paths do not intersect with each other and no two paths in P*(Gs') share the same pair of end vertices, thus we can merge one path at a time. Let Mv'' denote the isomorphism from V*(Gs') to V(Gs'') and Mp'' the isomorphism from P*(Gs') to E(Gs''). 11
Notice that (Mv'', Mp'') is a composition of type (ii) mappings. Since (Mv', Mp') and (Mv'', Mp'') are isomorphisms, we may define Mv''' = Mv ° (Mv')–1 ° (Mv'')–1 and Mp''' = Mp ° (Mp')–1 ° (Mp'')–1 s.t. both Mv'' : V(Gs'') → V(Gc) and Mp'' : E(Gs'') → E(Gc) are surjective mappings. Notice that (Mv''', Mp''') is a composition of type (iii) mappings. Therefore, the proposition is proven. Definition 1 (Consistency). We say Gc is consistent with Gs with respect to (Mv, Mp) if Mv is a
surjective mapping from V* to V(Gc) and Mp is a surjective mapping from P* to E(Gc) for some V* ⊆ V(Gs) and P* ⊆ P(Gs) such that conditions (A1), (A2) and (A3) hold. At present we do not provide a means to verify that a given ℜ generates only the consistent pairs (Gs, Gc). The verification of correctness of a given ℜ represents a potential topic for future research. The research on checking consistency [6,11,2] may be helpful towards this objective, although it does not directly deal with generating consistent representations. The main goal of this paper is to determine the necessary and sufficient conditions for preserving the consistency between the client and server application states. Proposition 1 provides a good decomposition of the mapping from Gs to Gc, which enables us to claim the following reductions of the problem: 1. We only need to solve the case of one client trying to maintain consistency with the server. 2. We only need to consider the mappings from Proposition 1 one at a time, i.e., individually. This claim is stated below as Lemma 1.
12
3. We only need to consider one-at-a-time of the four basic operations on server and client graphs, which are defined as follows. Definition 2 (Basic Graph Operations). The four basic operations on a graph G are:
1. Add an isolated vertex (f1) 2. Delete an isolated vertex (f2) 3. Add an edge (f3) 4. Delete an edge (f4) Since any operation on a graph can be expressed as a composition of these four basic operations, we can express the user interaction on either Gs or Gc graph as follows: Gs(t+1) = Fs(Gs(t)),
Gc(t+1) = Fc(Gc(t)),
where Fs and Fc are compositions of f1, f2, f3 and f4. Let M denote the pair (Mv, Mp) of mappings from Gs to Gc that satisfies the conditions (A1)– (A3), i.e., Gc = M (Gs). Definition 3 (Consistency Maintenance). The system is maintaining consistency between the
applications as the user interaction modifies graphs Gs and Gc if the following is true. The system can find some Fc and M(t+1) if Fs is applied at server side, or it can find some Fs and M(t+1) if Fc is applied at client side, such that the following diagram commutes:
13
(t ) Gs (t ) M → Gc (t )
↓ Fs
↓ Fc
(1)
M ( t +1)
Gs (t + 1) → Gc (t + 1) We use the following lemma to make our discussion concise. Lemma 1. To analyze the consistency problem between the client and server graphs, it is
sufficient to consider the mappings from Proposition 1 independently. Proof. Suppose the mapping M from the super graph Gs to the client graph Gc is a composition
of two mappings M1 and M2. We may assume that there is an intermediate graph G1 owned by a hypothetic client so that M1 maps Gs to G1and M2 maps G1 to Gc. If we can solve the problem of maintaining consistency between G1 and Gs with mapping M1, and the problem of maintaining consistency between G1 and Gc with mapping M2, we should be able to maintain the consistency between Gs and Gc with mapping M2 ° M1. This is illustrated in the following diagram. 1 (t ) 2 (t ) Gs (t ) M → G1 (t ) M → Gc (t )
↓ Fs
↓ F1 M1 ( t +1)
↓ Fc M 2 ( t +1)
Gs (t + 1) → G1 (t + 1) → Gc (t + 1)
By induction on the number of mappings from Proposition 1 that compose M, the statement is true. We now analyze the problem of maintaining consistency for the mappings from Proposition 1 under the four basic operations on the client or server side. We state our main result as the following proposition. Proposition 2. Let Gs and Gc be the super graph and client graph, respectively, and let the
14
relation between Gs and Gc satisfy (A1)–(A3). Then, given M(t) and one of Fs and Fc, we can exactly derive M(t+1) and the other one of Fc and Fs, respectively, such that the diagram from Definition 3 commutes. This means that the consistency between Gs and Gc can be maintained. Proof. Due to Proposition 1 and Lemma 1 it suffices to discuss how to maintain consistency
between Gs and Gc whenever M(t) is a type of mapping from Proposition 1. Our task is easy in case M(t) is an isomorphism. Notice that all three types of the mappings in Proposition 1 are very close to an isomorphism except for some part of Gs such as a path or a subset of vertices. Therefore, our discussion focuses on those parts of Gs and Gc where M(t) is not isomorphic. The discussion follows in the next three sections. We use the rule set ℜ to generate the initial Gs → Gc mapping and we also use it in the process of maintaining consistence under the user interaction, as will be detailed below. We assume that the user can install new rules ℜ dynamically at runtime.
2.1 Case 1: Client’s Graph is Isomorphic to a Subgraph of the Super-graph
Let Gs* denote a subgraph of super-graph Gs and Λ is an isomorphism from Gs* to the client’s graph Gc. Fig. 2 shows the algorithm for Case 1 assuming that Fs or Fc is one of the basic operations. The first branching selects whether Fs is applied at server side or Fc is applied at client side. In the first branch, the algorithm determines Fc and M(t+1) and in the second branch it determines Fs and M(t+1). Note that in Case 1 Mv = Λ and Mp is the induced isomorphism from E(Gs*) to E(Gc). Therefore, we consider the construction of Λ(t+1) which implies the construction of M(t+1).
15
1
Gs (server state)
4
5 isolated vertex
add v
Op type?
Either Gs*(t+1)= Gs*(t) Gc(t+1) = Gc(t). Or Gs*(t+1)= Gs*(t+1) ∪ v Gc(t+1) = Gc(t) ∪ v'. [ Determined by ℜ ]
delete v
If v ∉Gs*(t), Gc(t+1) = Gc(t). Else v ∈Gs*(t), Gc(t+1) = Gc(t) \ Λ(v).
Op target?
Which graph is updated?
Gc (client state)
add e
7
6 isolated vertex
edge
Op type?
Either Gs*(t+1)= Gs*(t) Gc(t+1) = Gc(t). Or Gs*(t+1)= Gs*(t+1) ∪ v Gc(t+1) = Gc(t) ∪ v'.
delete e
add v
Gs(t+1) = Gs(t) ∪ v', Gs*(t+1) = Gs*(t) ∪ v'.
If e ∉Gs*(t), Gc(t+1) = Gc(t).
Op type?
delete v
Gs(t+1) = 1 Gs(t) \ Λ– (v), Gs*(t+1) = Gs*(t) \ Λ–1(v)
Op target?
edge
add e
Op type?
Gs(t+1) = Gs(t) ∪ e', Gs*(t+1) = Gs*(t) ∪ e'.
delete e
Gs(t+1) = 1 Gs(t) \ Λ– (e), Gs*(t+1) = Gs*(t) \ Λ–1(e)
Else e ∈Gs*(t), Gc(t+1) = Gc(t) \ Λ(e).
[ Determined by ℜ ]
Fig. 3 Algorithm for Case 1: Gc ≅Λ Gs*, which is a subgraph of Gs. The entry point 1 is from Fig. 2.
The algorithm includes several places where a choice of action has to be made when determining F and M(t+1). The rule set ℜ defined by the application developer selects one choice but all the possible choices maintain consistency. For example, when an isolated vertex v is added at the
16
server side to Gs, there are two possible options: either (1) to include v into Gs* and add a corresponding vertex to Gc; or (2) keep both Gs* and Gc unchanged. When an isolated vertex v is deleted from Gs, if v belongs to Gs* then the corresponding vertex in Gc should be deleted. Otherwise both Gs* and Gc remain unchanged. When an edge e is added at the server side to Gs, there are two choices: either (1) to include e into Gs* and add a corresponding edge to Gc; or (2) keep both Gs* and Gc unchanged. When an edge e is deleted from Gs, if e belongs to Gs*, then the corresponding edge in Gc should be deleted. Otherwise both Gs* and Gc remain unchanged. When an isolated vertex v is added at the client side to Gc, a new vertex v' corresponding to v is added to both Gs and Gs*. When an isolated vertex v is deleted from Gc, the vertex corresponding to v is removed from Gs and Gs*. When an edge e is added to Gc, a new edge is added to both Gs and Gs* according to M. When an edge e is deleted from Gc, the edge corresponding to e is removed from both Gs and Gs*.
2.2 Case 2: Client’s Graph is Obtained by Merging a Path in the Super-graph
Let Gc denote the client’s graph obtained from the super-graph Gs by merging a path p of length at least 2 in Gs to an edge ec in Gc. Let V(p) be the set of internal vertices of degree two in the path p. Let Λ be the isomorphism from the vertex set V*=V(Gs)\V(p) to the vertex set of the client’s graph Gc. Note that in this case Mv = Λ is an isomorphism from V(Gs)\V(p) to V(Gc) and Mp maps p to ec and is an isomorphism from E(Gs \ p) ∪ p to E(Gc) induced by Λ. Therefore, we consider the construction of Λ(t+1) and mapping on p which imply the construction of M(t+1). If a new vertex v is added to Gs with a vertex corresponding to v added to Gc, Λ(t+1) is an extension of Λ(t) with v added to its domain. On the other hand, if both vertex v∈V* and
17
2
Gs (server state)
isolated vertex
edge
Op target?
4
Which graph is updated?
add e
Op type?
e = uv, If u,v ∉ V(p), go to 5,
Gc (client state)
isolated vertex
6
delete e
If e ∉ p, go to 5, Else e∈p, Gc(t+1) = Gc(t) \ ec.
edge
Op target?
add e
7
Op type?
delete e
If e ≠ ec, go to 7, Else e=ec, Gs(t+1) = Gs(t)\ p.
Else u∈V(p) or v∈V(p), Gc(t+1) = Gc(t).
Fig. 4. Algorithm for Case 2: Gc is obtained by merging a path p in Gs, Gc – ec ≅Λ Gs – p. The connector points refer to the algorithm in Fig. 3.
Λ(v)∈V(Gc) are deleted from Gs and Gc, respectively, Λ(t+1) is a restriction of Λ(t) with v
removed from its domain. Remark 2. In the following discussion, we only consider the updates that involve p at the server
side or ec at the client side. This is because if we remove p from Gs and ec from Gc, the remaining 18
v1
v1 v2 v3 v4 v5
v6
v7
v6 v9
v8
v5
v7
v8
v2 v3 v4 v5
v6 v9
Gs
v1
v
v7
v8
v7
v6 v9
v8 Gs
v7
Gc
(b)
v1
v6
v5
v9
Gs
(a)
e
v6 v9 v8
Gc
v2 v3 v4 v5
v1
v
v1
v1
v5
v2 v3 v4 v5
v8
v7
v6 v9
v8
Gc
v1
v7
v6 v9
Gs
(c)
v5
v7 v9
v8 Gc
(d)
Fig. 5. In the initial state (a), the client’s graph is obtained by merging a path in the super-graph. The following three cases show different operations on the server graph. (b) Adding a vertex v and an edge at the server side. (c) Adding an edge e at the server side. (d) Deleting an edge at the server side.
part of Gs is isomorphic with Gc and this is a special case of what was discussed in Section 2.1. When adding an edge e=uv to Gs, the only case that p is involved is when the new edge e is incident to one or two internal vertices of p (see Fig. 5c). Since the internal vertices of p are not mapped to Gc, there should be no change in Gc. When deleting an edge e from Gs, the only case that p is involved is when e is part of p. In this 19
case, ec should be removed from Gc since p no longer exists after e is deleted (see Fig. 5d). If an edge ec is deleted from Gc, the corresponding path p should be removed from Gs. If the edge to be deleted from Gc is not ec, this is considered in Section 2.1.
2.3 Case 3: Client’s Graph is Obtained by Contracting a Subset of Vertices in Gs
Let Gc denote the client’s graph obtained from the super-graph Gs by contracting a subset Vs of at least two vertices of Gs to a vertex vc of Gc. Let Λ be the isomorphism from the vertex set V(Gs)\Vs to the vertex set V(Gc)\{vc}. Note that in this case Mv maps Vs to vc and Mv = Λ when Mv is restricted to V(Gs)\Vs. Mp is a surjective mapping from E(Gs) to E(Gc) induced from Mv. Therefore, it suffices to construct Λ(t+1) and mapping on Vs which imply the construction of M(t+1). Fig. 6 shows the algorithm for this case. Remark 3. In what follows, we will only consider the updates that involve Vs at the server side
or vc at the client side. This is because if we remove Vs from Gs and vc from Gc, the remaining part of Gs is isomorphic with Gc which is a special case of what is discussed in Section 2.1. When adding an edge e=uv to Gs, the only case Vs is involved is when at least one end vertex of e belongs to Vs. This can be subdivided into two cases: •
Both end vertices of e belong to Vs. In this case, nothing should happen at the client side because both vertices are contracted to a single vertex vc in Gc.
•
Only one end vertex u of e belongs to Vs. There are two sub-cases. If e is the only edge from v incident to some vertex in Vs, then a new edge between vc and Λ(v) should be added in Gc (see Fig. 7). Otherwise, nothing should happen at the client side because 20
3
Gs (server state)
isolated vertex
add v
Op type?
If v ∉ Vs , go to 4.
Or go to 4.
Else v ∈ Vs, Gc(t+1) = Gc(t).
Gc (client state)
edge
add e
delete v
Either Vs(t+1) = Vs ∪ {v}
[ Determined by ℜ ]
Op target?
Which graph is updated?
isolated vertex
Op type?
e=uv Case 1: u,v ∈ Vs , Gc(t+1) = Gc(t). Case 2: u ∈Vs , v ∉Vs. Gc(t+1) = Gc(t) ∪ (Λ(v)vs) Case 3: u,v ∉ Vs, go to 5.
add v
delete e
Op type?
delete v
6
e=uv Case 1: u,v ∈ Vs , Gc(t+1) = Gc(t). Case 2: u ∈Vs , v ∉Vs. If ∃ w∈Vs, (wv) ∈ Gc(t), Gc(t+1) = Gc(t). Else Gc(t+1) = Gc(t) \ (Λ(v)vs) . Case 3: u,v ∉ Vs, go to 5.
If v=vc, Gs(t+1) = Gs(t)\Vs. Else go to 6.
Op target?
edge
add e
Op type?
delete e
e=uv
e=uv
If vc= v, Gs(t+1) = Gs(t) ∪ –1 (∪w∈W Λ (u) w) W ⊆ Vs is determined by ℜ
If vc= v, Gs(t+1) = Gs(t) \ –1 (Λ (u) w) ∀ w ∈ Vs. Else go to 7..
Else go to 7.
Fig. 6. Algorithm for Case 3: Gc is obtained by contracting a vertex set Vs in Gs, Gc – vc ≅Λ Gs – Vs, |Vs | > 1.
there should already be an edge between vc and Λ(v). When deleting an edge e=uv from Gs, the only case Vs is involved is when at least one end vertex of e belongs to Vs. This can be subdivided into two cases:
21
v8
v8
v7 v2 v0
v1
v4
v3
v5
v6
v5
v6
(a)
(b)
v8
v8
v7 w
v2
v4
w v0
v1 v3
v5
v6
v5
(c)
v6
(d)
Fig. 7. Adding and deleting an edge at client side or server side: (a) the original graph Gs (b) client’s graph Gc obtained by contracting vertices v1, v2, v3, v4, v7 (c) Gs with a new vertex w and new edges wv8, wv2, wv3 and wv6 (d) the updated client graph.
•
Both of the end vertices of e belong to Vs. In this case, nothing should happen at the client side because both vertices are contracted to a single vertex vc in Gc.
22
•
Only one end vertex u of e belongs to Vs. There are two sub-cases. If e is the only edge from v incident to some vertex in Vs, then the edge between vc and Λ(v) should be deleted from Gc. Otherwise, nothing should happen at the client side because there is still an edge connecting v and a vertex in Vs.
When adding an edge e to client graph Gc, the only case vc is involved is when vc is an end vertex of e. Let u denote the other end vertex of e. Then at the server side, at least one edge that joins some vertices in Vs with Λ–1(u) should be added. This is determined by the rule set ℜ. When deleting an edge e from client graph Gc, the only case vc is involved is when vc is an end vertex of e. Let u denote the other end vertex of e. Then at the server side, all edges that join some vertices in Vs with Λ–1(u) should be removed.
2.4 An Interesting Example
Here we provide an example of maintaining consistency in a heterogeneous groupware framework presented in [10]. Two users collaborate on a furniture arrangement task but with different versions of the shared applications. User A participates from a high-end workstation and sees a three-dimensional virtual world and user B participates from a PalmPilot V handheld and sees a two-dimensional rendering of the room floor plan. The participants use these applications as a tool to decide where they would like to have the moving company place their furniture when it is moved to their new office. Suppose the representation of the office is the super graph Gs, which includes all the detailed information. Let GA be graph of the representation seen by user A and GB be the graph of the representation seen by user B. Suppose that user A wants to show a desk, and starts by 23
v8
v8
v7 v2 v0
v1
v4
v3
v5
v6
v5
v6
(a)
(b) v8
v8 w3 v7 w1
w2
v2
w0
w4 v4
v0
v1 v3
v5
v5
v6
(c)
v6
(d)
Fig. 8. Server graph (a) and the corresponding client graph (b). Adding a tree at server side (c) results in only adding an edge and a vertex at the client side (d).
assembling the parts of the desk from simple geometric figures, such as 3D blocks of different shapes. According to the rule set ℜ, nothing is visible in the user B’s display until user A creates the whole desk, at which time the desk appears on user B’s screen. That means, sometimes when we add some vertices and edges at the server side, there are no any operations at the client side. Once a certain number of vertices and edges are added, the set of new vertices will be contracted to a new vertex at the client side. An example is shown in Fig. 8, where a tree was added to the super graph, while the resulting graph at the client side is obtained from the graph in Fig. 8b by adding one vertex w0 and one edge w0v0.
24
u1
v1
u2
u4
u3
u5
v2
(a)
v3
(b)
Fig. 9. The mapping Mv from vertices of the server’s graph in (a) to vertices of the client’s graph in (b) is defined as follows: u1→v1; {u2,u5} → v2; {u3,u4} →v3. Notice that the server’s graph is a DAG while the client’s graph has a cycle.
2.5 Directed Acyclic Graphs
The above algorithm can also be extended to the case where the graphs at the server side and client side are both directed graphs. However, if the server graph Gs is a directed acyclic graph (DAG), our three conditions (A1–A3) do not guarantee that the client graph Gc is also a DAG (see Fig. 9). To verify whether Gc is a DAG we can run the Djikstra’s algorithm to find the shortest path from every vertex of Gc to itself.
25
3 GRAPHS WITH VERTICES HAVING PROPERTIES The model presented above only deals with the topological structure of graphs. In addition to this we need to consider how to maintain consistency when property vectors are attached with vertices. Let Π(v) denote the property vector of vertex v. Note that the properties may sometimes be represented implicitly. For example, in some 2D graphics applications the left-to-right order of vertices represents the spatial order of the corresponding objects in the depth axis. In addition to the basic operations on the topological structure of the graph (Definition 2), we have the following basic operations on property vectors of vertices: 1. Add a property (f5) 2. Delete a property (f6) 3. Set a property to a new value (f7) In most cases the graph topology is independent of the property vectors. In these cases the above three operations do not affect the topological structures of the graphs Gs and Gc. However, it may be that a property p of a vertex vc ∈ Gc represents some property of the topological structure of the graph Gs (a subgraph), which resulted from data compression. For example, a desk representation on one site is a parts-subgraph with vertices and associated properties. At another site, the desk representation is a single vertex the properties of which count the number of different parts of the desk (shelves, legs, etc.). An operation on the property vector p could then change the topological structure of the graph Gs. We can for the purpose of analysis expand each vertex vc in Gc with topological properties and add an extra vertex for each topological property. Thus, we can again reduce the problem to the case where client’s graph is just one of the three 26
types of mappings in Proposition 1. The vertex properties are modified under the following circumstances. For a vertex vc∈V(Gc), let Vs=Mv–1(vc) be the set of vertices that mapped to vc under Mv. We modify the property vector of vc only if either an operation is applied to the property vector of a vertex in Vs or the set Vs is changed (e.g., a vertex is deleted or added). Conversely, we modify the property vectors of vertices in Vs if an operation is applied on a property of vc. Property types are domain-specific and need to be converted between the domains that share information. The mapping from the property vectors attached to vertices in Vs to that of vc depends on the application domain. Graph topology mappings considered in Section 2 are also domain-specific, but they are compositions of the basic operations f1–f4. Unlike these, property conversions between different domains can get arbitrarily complex and are not known in advance. An example is given in Section 3.1 below. Another issue is which properties to change when there is a one-to-many correspondence between the client and server graphs. If Vs is singleton {vs}, the entries of Π(vc) form a subset of entries of Π(vs). If Vs has cardinality greater than 1, an entry in Π(vc) can be the average of that of Π(v) for all v∈Vs, or it can be computed in some other way, depending on the property type.
3.1 Example of Property Type Conversion
The following example illustrates how application-specific and complex the property type conversion can be. Suppose we have two clients collaborating, where one client application represents objects in 3D and the other one in 2D space. The 3D application allows inserting VRML objects, represented in the scene hierarchy as sub-trees whose vertices are 3D polygons.
27
y (b) (a)
x (c)
z
Fig. 10. (a) Coordinate system of the user view in the 3D application, where the z-axis comes out of the screen towards the user. (b) Example of an object in the 3D space. (c) The same object in the 2D application projected to the x-z plane (top view).
3D applications typically use the right-hand coordinate system (Fig. 10). Every vertex from the 3D graph has a corresponding vertex in the 2D graph, which is a projection onto the x-z plane. One of the object properties is its spatial transformation, which is different in 2D than in 3D. In order to define a generic 3D-to-2D conversion of the transformation property, we assume that 2D applications are capable of handling spatial transformations composed of translation, (x,y) pair, rotation (angle), and scaling, (sx,sy) pairs. 3D applications handle transformations composed of translations in the 3D space, rotations around the three axes, and scaling.
28
When an object is an aggregate of object parts, the spatial transformation in 2D is not a simple projection of the 3D transformation to a 2D plane. Let us consider a vertex v in 3D whose transformation property is a matrix T, relative to the ancestor vertex. There is a corresponding vertex v' in 2D for which the transformation property is a matrix T'. The absolute transformation R of the vertex v in 3D is obtained by multiplying the transformation matrices of its ancestor vertices: T1×T2×T3×….×T = R, where Ti is the transformation of the ancestor of v at the hierarchy depth i of the scene tree. Similarly, the absolute transformation R' of the element v' in 2D is obtained as: T1'×T2'×T3'×….×T' = R' In order to maintain consistent transformations of v and v', the matrix R' corresponds to the projection of the 2D components of R. Let TRANSL(M) denote a 2D matrix corresponding to the translation components of a 3D matrix M in the x-z plane, let ROTY(M) be a 2D matrix corresponding to the components of the 3D matrix M for rotation around the y-axis, and let SCALE(M) be a 2D matrix corresponding to the scaling components of M in the x-z plane. Then: R' = TRANSL(R) × ROTY(R) × SCALE(R) T' can be computed as: T' = (T1'×T2'×….×Tp')–1 × R', where Tp' is the transformation of the parent of vertex v', or T' = (Rp')–1 × R', where Rp' is the absolute transformation of the parent of vertex v'. So,
29
T' = (Rp')–1 × TRANSL(R) × ROTY(R) × SCALE(R)
(2)
Since the multiplication of each vertex from the root of the scene hierarchy up to the vertex v' is not computationally efficient, we maintain a copy of the absolute transformation of each vertex, so the computation of T' is performed in time O(1). In addition to transformations, the coordinate properties of leaf vertices in the 3D graph are mapped to 2D coordinates. A point p = (x, y, z) in 3D corresponds to a point p' = (x', y') in 2D, where p' is the projection in 2D of the point resulting from ROTX(R) × ROTZ(R) × p, where R is the absolute transformation of the corresponding vertex in the 3D graph, and ROTX(M) and ROTZ(M) are the 2D matrices composed of the components the 3D matrix M for rotations around x-axis and z-axis, respectively. This approach has some drawbacks since a property change for a vertex of one client graph is not always localized to a property change of a single vertex in another client graph. A change in the transformation property of a vertex which is the root of a sub-tree in the 3D graph may cause a change of the transformation property for all vertices in the corresponding sub-tree of the 2D graph. This does not occur if the transformation is a translation or a rotation around the y-axis in the 3D environment, since it suffices to apply a 2D transformation in Eq. (2) to the corresponding sub-tree root vertex in the 2D graph. However, for rotations in the other two axes the corresponding 2D transformation must be applied to all vertices of the sub-tree in 2D.
4 AN APPLICATION SCENARIO One of the applications of the consistency 30
model is data abstraction or level-of-detail
filtering of the shared data. In this setting, the users subscribe to the server to only receive information about elements up to a certain depth in the document hierarchy. An example could be in browsing documents to receive only the section titles so to conserve wireless network bandwidth. Another application scenario is illustrated in [10]. We implemented collaboration between client applications that use 3D and 2D spatial environments as described in Section 3.1 above. Level of detail is represented in the 2D application as bounding boxes around the corresponding object parts, so size and location of these boxes match those of the detailed 3D version of the group. Changing the level-of-detail for the 2D application means installing a new rule set ℜ: any time the user selects different level-of-detail, a new ℜ is installed or the existing one is updated. In order to demonstrate the performance gains, a simple collaboration setup was used as follows: •
Two clients connect to the server. One of them is using a 3D application. The other is using a 2D application.
•
A set of objects is created in the 3D client, using small VRML models (< 40KB in size), and placed into the environment (Fig.11).
•
A single object is translated in the horizontal plane (x-y in 3D), and then rotated around the y-axis, at a rate of 30 increments per second, the update rate required for real-time visual environments.
•
Each object is rotated around the x-axis, at a rate of 30 increments per second.
31
table1
boxes
cubes3
bookcase3
cubes2
bookcase
cubes
boxes2
chair4
chair5
design1
chair3
couch3
key2
Fig. 11. Object types used in the experiment. The top row gives the object name, the middle row shows its 3D appearance and the bottom row shows its 2D appearance with level of detail 3.
•
The experiment is repeated several times, varying the level-of-detail at the 2D client.
•
The size of the incoming messages at the 2D client is measured.
32
100000 90000
message size (bytes)
80000 70000 original
60000
lod=4
50000
lod=3
40000
lod=2 lod =1
30000 20000 10000
ke y2 co uc h3 ch ai r3 de si gn 1 ch ai r5 ch ai r4 bo xe s2 cu b b o es ok ca se cu b b o es2 ok ca se 3 cu be s3 bo xe s ta bl e1
0
8500 8000 7500 7000 6500 6000 5500 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0
original lod=4 lod=3 lod=2 lod =1
bo ok ca bo se (t ok ca 1) se (t2 ) ke y2 de si gn 1 ch ai r4 ch ai r5 ch ai r3 co uc h3 bo xe s2 cu be s3 cu bo be ok s ca se (t3 ) bo xe bo s ok ca se 3 cu be s2 ta bl e1
message size (bytes)
object type
object type
Fig. 12. Top figure shows the network load for object creation. Bottom figure shows the network load for object manipulation.
The first stage of the experiment involves the creation of objects in the 3D application. The
33
results are shown in Fig. 12 (top). The curves show the message size received by the 2D client, in bytes, for each of the object types created during the experiment. The reduction of the message size due to level of detail is not uniform because the complexity of the objects depends on two factors: how complex is the object’s hierarchy (this relates to the depth of the hierarchy and the number of children per vertex), and how complex are the leaf vertices (that is, the relative complexity of the polygons in terms of the number of vertices). Objects with complex leaves show a significant reduction in message size, but once the maximum depth of the object is reached, the reduction drops dramatically (e.g., object type “boxes2”). Conversely, objects with a complex structural hierarchy tend to show a uniform reduction of the message size as level of detail decreases. The second part of the collaborative setting involved object manipulation, where the objects are translated and rotated as described above, and we measured the effects of those updates in the amount of information received by the 2D client. Fig. 12 (bottom) shows the results. The algorithm has no performance issues for topological structure consistency since it involves only few simple graph operations. The performance may be an issue for property conversions if the conversion involves complex operations on entire subtrees, as explained in Section 3.1. For the object type bookcase, the two initial transformations (t1 and t2) show no impact in the message size, since they are simple translation (t1) and rotation in a 2D plane (t2). For the other cases, the message size increased for levels of detail greater than 2. This overhead, however, is necessary if we wish to maintain consistent views of the objects in both domains. There are other approaches to avoid this overhead: •
Represent level-of-detail groups with simpler elements, such as icons, which do not 34
require exact visualization of the relative size of the sub-tree. This approach lacks the spatial consistency and is even less detailed than the first approach. However, it is useful in applications where the location of low-detail elements is more important than the exact appearance and spatial relations between them. •
Provide the 2D client with the capability to handle 3D transformations and project them into a 2D plane. This approach, however, implies a change in the nature of the client, which actually becomes a 3D application, rather than a 2D one, with increased computational requirements at the client side.
There is an interesting problem of selecting levels of details. Given limited resources, the client cannot handle the full-detailed graph. The question is, given the limited resources, what is the best client graph the client can handle? This can be considered as an optimization problem and currently we are at the stage of defining the problem. We will need to look at real applications to find the suitable cost function and the target function, which we want to maximize.
5 CONCLUSION This paper investigates the problem of maintaining consistent application state across collaborating applications with heterogeneous data representations. We assume that the application state can be represented as a graph data structure and derive a set of conditions on the state transformations under which the state consistency can be maintained across different copies of an application. The focus of this paper is on consistency maintenance rather than on checking that the different copies are consistent. We start with the conditions on the set of rules that 35
describe the relationship between the graphs on different sites. Based on the conditions, we decompose the problem into three special cases, which can be considered individually. We present our solution to the consistency maintenance problem under these three cases. In addition to maintaining consistency for graphs topological structure, we also consider how to maintain consistency when property vectors are attached with vertices. There is no general solution since property type conversion is application specific. Lastly, we present an example of type conversion and illustrate an application scenario benefiting from heterogeneous state representations. Our continuing research focuses on checking the consistency of the rules for generating different representations and on determining the rules so that the users can equitably collaborate using diverse representations.
REFERENCES 1. K. P. Birman, Building Secure and Reliable Network Applications. Manning Publications Co., 1996. 2. E.A. Boiten, H. Bowman, J. Derrick, P.F. Linington, and M.W.A. Steen, “Viewpoint consistency in ODP,” Computer Networks, vol. 34, no. 3, pp. 503-537, August 2000. 3. J. A. Bondy and U. S. R. Murty, Graph Theory with Applications, New York: American Elsevier Publishing Co., 1976. 4. P. Dewan and A. Sharma, “An Experiment in Interoperating Heterogeneous Collaborative Systems,” Proc. Sixth European Conf. on Computer Supported Cooperative Work
36
(ECSCW’99), Kluwer Acad. Publ., Copenhagen, Denmark, pp. 371-390, September 1999. 5. C. A. Ellis and S. J. Gibbs, “Concurrency Control in Groupware Systems,” Proc. Nineteenth ACM SIGMOD Conf. of Management of Data, Seattle, WA, pp. 399-407, 1989. 6. A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B. Nuseibeh, “Inconsistency Handling in Multi-Perspective Specifications,” IEEE Transactions on Software Engineering, vol. 20, no. 8, pp. 569-578, August 1994. 7. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley Longman, Inc., 1995. 8. R. Han, V. Perret, and M. Naghshineh, “WebSplitter: A Unified XML Framework for MultiDevice Collaborative Web Browsing,” Proc. ACM Conf. on Computer-Supported Cooperative Work (CSCW'00), Philadelphia, PA, pp. 221-230, December 2000. 9. A. Karsenty, C. Tronche, and M. Beaudouin-Lafon, “GroupDesign: Shared Editing in a Heterogeneous Environment,” USENIX Computing Systems, vol. 6, no. 2, pp. 67-195, Spring 1993. 10. I. Marsic, “An Architecture for Heterogeneous Groupware Applications,” Proc. Twenty-third IEEE/ACM Int’l Conf. on Software Engineering (ICSE 2001), Toronto, Canada, pp. 475-484, May 2001. 11. C. Nentwich, L. Capra, W. Emmerich, and A. Finkelstein, “xlinkit: a Consistency Checking and Smart Link Generation Service,” To appear in ACM Transactions on Internet Technology (TOIT).
37
12. D. R. Olsen, S. Jefferies, T. Nielsen, W. Moyes, and P. Fredrickson, “Cross-Modal Interaction Using XWeb,” Proc. ACM User Interface Software Technologies (UIST'00), San Diego, CA, pp. 191-200, 2000. 13. J. F. Patterson, R. D. Hill, S. L. Rohall, and W. S. Meeks, “Rendezvous: An Architecture for Synchronous Multi-User Applications,” Proc. ACM Conf. Computer-Supported Cooperative Work (CSCW'90), Los Angeles, CA, pp. 317-328, Oct. 1990. 14. M. Roseman and S. Greenberg, “Building Real-Time Groupware with GroupKit, a Groupware Toolkit,” ACM Transactions on Computer-Human Interaction, vol. 3, no. 1, pp. 66-106, March 1996. 15. E. Sciore, M. Siegel, and A. Rosenthal, “Using Semantic Values to Facilitate Interoperability Among Heterogeneous Information Systems,” ACM Transactions on Database Systems, vol. 19, no. 2, pp. 254-290, June 1994. 16. C. Sun and D. Chen, “Consistency Maintenance in Real-Time Collaborative Graphics Editing Systems,” ACM Transactions on Computer-Human Interaction, vol. 9, no. 1, pp. 1-41, March 2002. 17. World Wide Web Consortium. Extensible markup language. At: http://www.w3.org/XML/.
38
