43
Model Consistency for Distributed Collaborative Modeling Gerson Sunyé University of Nantes, France [email protected] 1

Model Consistency for Distributed Collaborative Modeling

Embed Size (px)

Citation preview

Page 1: Model Consistency for Distributed Collaborative Modeling

Model Consistency for Distributed

Collaborative ModelingGerson Sunyé

University of Nantes, France

[email protected]

1

Page 2: Model Consistency for Distributed Collaborative Modeling

Collaborative Modeling

• Growing need for tools/techniques that enable effective collaboration.

• Our goal is propose an approach that provides:

• Distribution: distributed participants with no centralized server.

• Reactivity: fast remote change integration.

• Synchrony: local changes are broadcast to others.

2

Page 3: Model Consistency for Distributed Collaborative Modeling

Collaborative Modeling

Anna

Carol

Béatrix

3

Page 4: Model Consistency for Distributed Collaborative Modeling

Start Transaction, Commit, Rollback, Lock, Undo, End Transaction,

etc.

Anna Carol Béatrix4

Page 5: Model Consistency for Distributed Collaborative Modeling

Checkout, Commit, Modify, Update , Merge, Show History, etc.

EMFStore

Anna Carol Béatrix5

Page 6: Model Consistency for Distributed Collaborative Modeling

What if they adopted a different approach?

Anna Carol Béatrix6

Page 7: Model Consistency for Distributed Collaborative Modeling

Quick focus

on Eclipse

modeling

tools…

7

Page 8: Model Consistency for Distributed Collaborative Modeling

Modeling Tool

gef

8

Page 9: Model Consistency for Distributed Collaborative Modeling

A

B

modeling tool

create Vertex v1

set v1 #name ‘A’

create Vertex v2

set v2 #name ‘B’

create Edge e1

set e1 #from &v1

set e1 #to &v2

9

Page 10: Model Consistency for Distributed Collaborative Modeling

A

create vertex v1

set v1 #name ‘A’

A A

B

create Vertex v2

set v2 #name ‘B’

BB

create Edge e1

set e1 #from &v1

set e1 #to &v2

Anna Carol Béatrix10

Page 11: Model Consistency for Distributed Collaborative Modeling

It looks simple!

11

Page 12: Model Consistency for Distributed Collaborative Modeling

A A A

BBB

Most operations are

independents!

DE

F

E ED D

FF

Anna Carol Béatrix12

Page 13: Model Consistency for Distributed Collaborative Modeling

A A A

BBB

Some operations

dependent on others

!

DD

create vertex v4

create edge e2

set e2 #from v1

set e2 #to v4

?create edge e2

set e2 #from v1

create vertex v4

set e2 #to v4

Anna Carol Béatrix13

Page 14: Model Consistency for Distributed Collaborative Modeling

A A A

BBB

Some operations are

equivalents !

delete e1 delete e1

Anna Carol Béatrix14

Page 15: Model Consistency for Distributed Collaborative Modeling

Anna Carol Béatrix

A A A

BBB

Some operations are

conflictual !

A

M K L

set v1 #name ‘K’

set v1 #name ‘L’

set v1 #name ‘L’

set v1 #name ‘M’

set v1 #name ‘M’

set v1 #name ‘K’

set v1 #name ‘M’ set v1 #name ‘K’ set v1 #name ‘L’

15

Page 16: Model Consistency for Distributed Collaborative Modeling

set v1 #name ‘L’

set v1 #name ‘M’set v1 #name ‘K’

I’m annoyed, I cannot order

these operations

Moreover, I don’t know how Anna

and Béatrix ordered theirs

Carol

16

Page 17: Model Consistency for Distributed Collaborative Modeling

There are (at least) two solutions

17

Page 18: Model Consistency for Distributed Collaborative Modeling

Solution 1: Vector Clocks

• Algorithm for generating a partial ordering of events.

• Each node keeps a vector clock containing its knowledge of other

nodes’ clocks.

• The entire vector is sent along with messages.

18

Page 19: Model Consistency for Distributed Collaborative Modeling

Solution 2: Use Semantic Casual Dependence

opA = createDir(d) opB = createFile(d/f)

The dependence is declared regarding the preconditions of an operation.

1. opA = createDir(d)

2. opB = createFile(d/f)

19

Page 20: Model Consistency for Distributed Collaborative Modeling

Semantic Casual Dependence

First, let us have a closer look at the model operations

20

Page 21: Model Consistency for Distributed Collaborative Modeling

Create

Delete

Get

Set

Add

Remove

Unset

Move

Clear

IsSet

IsEmpty

Size

Contains

IndexOf

LastIndexOf

ToArray

21

Page 22: Model Consistency for Distributed Collaborative Modeling

Read Object

Multivalued Features Monovalued Features

Create DeleteGet

SetAdd Remove UnsetMoveClear

IsSet

IsEmpty

Size

Contains

IndexOf

LastIndexOf

ToArray

Read operations do not

need to be propagated

Object operations cannot

be conflictual

Multivalued feature

operations may be

conflictual

And so does

monovalued feature

operations

22

Page 23: Model Consistency for Distributed Collaborative Modeling

23

Page 24: Model Consistency for Distributed Collaborative Modeling

Only operations that

concern the same object

and/or the same feature

can be conflictual.

set v1 #name ‘A’ delete vertex v1

set e1 #to v1 set e1 #to v3

move v1 #label 1 3 add v1 #label ‘hey’

24

Page 25: Model Consistency for Distributed Collaborative Modeling

Only operations that have

the same original context

can be conflictual

set v1 #name ‘D’

previous=‘A’

set v1 #name ‘E’

previous=‘A’

set v1 #name ‘D’

previous=‘A’

set v1 #name ‘E’

previous=‘D’

25

Page 26: Model Consistency for Distributed Collaborative Modeling

Back to casual

dependence

26

Page 27: Model Consistency for Distributed Collaborative Modeling

Object

Multivalued Features Monovalued Features

Create Delete

SetAdd Remove UnsetMoveClear

27

Page 28: Model Consistency for Distributed Collaborative Modeling

ObjectObject Multivalued Features

Monovalued Features

Create Delete

Set

Add Remove

Unset

MoveClear

28

Page 29: Model Consistency for Distributed Collaborative Modeling

Multivalued

Features

Multivalued

Features

Multivalued

Features ObjectObject

Multivalued

Features

Monovalued Features

Create Delete

Set

AddRemove

Unset

Move Clear

29

Page 30: Model Consistency for Distributed Collaborative Modeling

Multivalued Feature Operations

• The “move” operation must be

executed first.{ ‘a’, ‘b’, ‘c’, ‘d’}

move(1,4) remove(‘b’)

{‘b’, ‘c’, ‘d’, ‘a’} { ‘a’, ‘c’, ‘d’}

move(1,4)remove(‘b’)

{‘c’, ‘d’, ‘a’} error

30

Page 31: Model Consistency for Distributed Collaborative Modeling

Multivalued Feature Operations

• The “move” operation must be

executed first.

• The “remove” operation must be

executed before “clear”.

{ ‘a’, ‘b’, ‘c’, ‘d’}

clear() remove(‘b’)

{} { ‘a’, ‘c’, ‘d’}

clear()remove(‘b’)

{}error

31

Page 32: Model Consistency for Distributed Collaborative Modeling

Multivalued Feature Operations

• The “move” operation must be

executed first.

• The “remove” operation must be

executed before “clear”.

• The “add” operation must be

executed after “clear”.

{ ‘a’, ‘b’, ‘c’, ‘d’}

clear() add(‘e’)

{} { ‘a’, ‘b’, ‘c’, ‘d’, ‘e’}

clear()add(‘e’)

{}{‘e’}

32

Page 33: Model Consistency for Distributed Collaborative Modeling

Monovalued

Features

Multivalued

Features

Multivalued

Features

Multivalued

Features ObjectObject

Multivalued

Features

Monovalued

Features

Create Delete

Set

AddRemove

Unset

Move Clear

33

Page 34: Model Consistency for Distributed Collaborative Modeling

set v1 #name ‘L’

set v1 #name ‘M’set v1 #name ‘K’

You did not solve my problem!

Operations of the same type can

still be conflictual!

Carol

34

Page 35: Model Consistency for Distributed Collaborative Modeling

What if we used a hash function?

set v1 #name ‘L’

set v1 #name ‘M’set v1 #name ‘K’

35

Page 36: Model Consistency for Distributed Collaborative Modeling

hash(‘M’) > hash(‘L’) > hash(‘K’)

36

Page 37: Model Consistency for Distributed Collaborative Modeling

A random choice, but which is the same for all participants.

A A A

BBB

A

M M M

set v1 #name ‘K’

set v1 #name ‘L’

set v1 #name ‘K’

set v1 #name ‘L’

set v1 #name ‘K’

set v1 #name ‘L’

set v1 #name ‘M’ set v1 #name ‘M’ set v1 #name ‘M’

37

Page 38: Model Consistency for Distributed Collaborative Modeling

Implementation Principles

• Participants perform and propagate local changes.

• Remote change integration may require change cancellation and re-

execution.

• Each resource, object, and feature has an unique identification.

• The original context is either:

• The last value (for monovalued features).

• A local modification counter (for multivalued features).

38

Page 39: Model Consistency for Distributed Collaborative Modeling

URI ID Node

“http://www.eclipse.org/gmt/2006/AM3" a Carol

“http://www.eclipse.org/gmt/2005/ATL" b Anna

"http://docs.oasis-open.org/wsbpel/2.0/executable" c Béatrix

https://github.com/tomp2p

Anna

Carol

Béatrix

Distributed

Resource Registry

39

Page 40: Model Consistency for Distributed Collaborative Modeling

Publish/Subscribe Protocol

for Change Propagation

MQTT

Broker

Anna

Caro

l

Béatrix

Anna

Caro

l

Béatrix

40

Page 41: Model Consistency for Distributed Collaborative Modeling

Conclusion

• Alternative to central server-based approaches.

• Scalability ensured by fixed-size messages.

• Limitations:

• Change integration may introduce syntax errors.

• Dependent attributes are not taken into account.

41

Page 42: Model Consistency for Distributed Collaborative Modeling

Future Work

• More complex scenarios:

• Long time absent participant.

• Support for large resources.

• Integration to (i) NeoEMF and to (ii) existing modeling tool.

• Real-world usability evaluation.

42

Page 43: Model Consistency for Distributed Collaborative Modeling

Thank you for you attention!

Icons made by Eucalyp and Freepik from Flaticon are licensed by Creative Commons BY 3.0

sunye/model-consistency

43

Any questions?