Model Consistency for Distributed Collaborative Modeling

Model Consistency for Distributed

Collaborative ModelingGerson Sunyé

University of Nantes, France

gerson.sunye@ls2n.fr

1

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

Collaborative Modeling

Anna

Carol

Béatrix

3

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

etc.

Anna Carol Béatrix4

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

EMFStore

Anna Carol Béatrix5

What if they adopted a different approach?

Anna Carol Béatrix6

Quick focus

on Eclipse

modeling

tools…

7

Modeling Tool

gef

8

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

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

It looks simple!

11

A A A

BBB

Most operations are

independents!

DE

F

E ED D

FF

Anna Carol Béatrix12

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

A A A

BBB

Some operations are

equivalents !

delete e1 delete e1

Anna Carol Béatrix14

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

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

There are (at least) two solutions

17

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

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

Semantic Casual Dependence

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

20

Create

Delete

Get

Set

Add

Remove

Unset

Move

Clear

IsSet

IsEmpty

Size

Contains

IndexOf

LastIndexOf

ToArray

21

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

23

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

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

Back to casual

dependence

26

Object

Multivalued Features Monovalued Features

Create Delete

SetAdd Remove UnsetMoveClear

27

ObjectObject Multivalued Features

Monovalued Features

Create Delete

Set

Add Remove

Unset

MoveClear

28

Multivalued

Features

Multivalued

Features

Multivalued

Features ObjectObject

Multivalued

Features

Monovalued Features

Create Delete

Set

AddRemove

Unset

Move Clear

29

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

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

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

Monovalued

Features

Multivalued

Features

Multivalued

Features

Multivalued

Features ObjectObject

Multivalued

Features

Monovalued

Features

Create Delete

Set

AddRemove

Unset

Move Clear

33

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

What if we used a hash function?

set v1 #name ‘L’

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

35

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

36

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

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

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

Publish/Subscribe Protocol

for Change Propagation

MQTT

Broker

Anna

Caro

l

Béatrix

Anna

Caro

l

Béatrix

40

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

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

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?