Interface contracts are sets of constraints specifying valid exchanges of messages between two or more peers. A contract violation occurs when one of the peers fails to fulfil one of these constraints and emits a message that is not a valid continuation of a message "trace". In some cases, the message that directly exposes the violation turns out to be the last of a succession of forced moves, while the "root cause" of the violation resides earlier in the trace and may emanate from a different peer. We formally define the notion of causality for interface contracts expressed in a first-order extension of Linear Temporal Logic. In particular, we show how the detection of root causes reduces to satisfiability solving of a precise set of formulæ. An experimental setup shows how causality can be analyzed automatically on a pre-recorded message trace.

1. Sylvain Hallé

2. A lighthearted introduction
Sylvain Hallé 2

3. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Sylvain Hallé 2

4. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Sylvain Hallé 2

5. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Rules
Sylvain Hallé 2

6. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
and O mu st alternate Moves
1. X
symbols
n’t put two
.
2. Ca
in sa me square
must be
ually, there
.
3. Event
Rules
a line of three O’s
Sylvain Hallé 2

7. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Rules
Sylvain Hallé 2

8. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Rules
Sylvain Hallé 2

9. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Rules
Sylvain Hallé 2

10. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Rules
Sylvain Hallé 2

11. A lighthearted introduction
Player ‘‘O’’ Player ‘‘X’’
Moves
Rules
Game
Sylvain Hallé 2

12. A lighthearted introduction
‘‘O’’ web service
‘‘X’’ web service
Sylvain Hallé 3

13. A lighthearted introduction
Move
‘‘O’’ web service
‘‘X’’ web service
Sylvain Hallé 3

14. A lighthearted introduction
<Move>
Message <Player>X</Player>
<Row>1</Row>
<Col>A</Col>
</Move>
‘‘O’’ web service
‘‘X’’ web service
Sylvain Hallé 3

15. A lighthearted introduction
<Move>
Message <Player>X</Player>
<Row>1</Row>
<Col>A</Col>
</Move>
Interface
contract ‘‘O’’ web service
‘‘X’’ web service
Sylvain Hallé 3

16. A lighthearted introduction
<Move>
Message <Player>X</Player>
<Row>1</Row>
<Col>A</Col>
</Move>
Interface
contract ‘‘O’’ web service
‘‘X’’ web service
Game
Sylvain Hallé 3

17. A lighthearted introduction
<Move>
Message <Player>X</Player>
<Row>1</Row>
<Col>A</Col>
</Move>
Interface
contract ‘‘O’’ web service
‘‘X’’ web service
Transaction
Sylvain Hallé 3

18. A more serious example
Shop service
Each has its own requirements on the
course of a transaction Customer
service
Sylvain Hallé 4

19. A more serious example
S1. All carts with more than three items are
labelled ‘‘large’’ and must be paid by credit
.
S2. Every cart created must be cbecked out
.
S3. Payment mode must be only one of
‘‘Credit’’ or ‘‘PayPal’’
C1. A cart created with a mode of payment
must be checked out with the same mode
of payment
Interface contract = ‘‘sum’’ (i.e. logical
conjunction) of individual requirements
Sylvain Hallé 5

20. Formalizing interface contracts
The service’s behaviour follows constraints on...
1. Sequences of operations only
2. Parameter values only
3. Both at the same time
LTL-FO+: extension of LTL with quantifiers on message
parameters (Hallé & Villemaire, EDOC 2008)
Sylvain Hallé 6

21. Formalizing interface contracts
LTL formula = assertion on a trace (of messages)
Ga "always a"
Xa "the next message is a"
Fa "eventually a"
aWb "a until b
abacdcbaqqtam...
G (a ® X b) FALSE Ø (q Ú t) W c TRUE
But what about data contents?
Sylvain Hallé 7

22. Formalizing interface contracts
What if symbols are XML documents?
LTL-FO+ = LTL + first-order quantification on
elements
Let...
p = argument of a function f...
filters acceptable values for x...
according to the current message s0
s |= $p x : j(x) Û $k : s |= j(k) AND k Îf(s0,p)
Sylvain Hallé 8

23. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1
p = a/b
Sylvain Hallé 9

24. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1 XPath expression
p = a/b
Sylvain Hallé 9

25. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1
p = a/b
f(s0,p) =
Sylvain Hallé 9

26. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1
p = a/b
f(s0,p) = {1,2}
Sylvain Hallé 9

27. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1
p = a/b
f(s1,p) =
Sylvain Hallé 9

28. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1
p = a/b
f(s1,p) = {}
Sylvain Hallé 9

29. LTL-FO+
Example:
<d>
<a> <e>1</e>
<b>1</b> <e>2</e>
s= <b>2</b>
</a>
</d>
<c>5</c>
<c>5</c> <c>6</c>
s0 s1
TRUE "a/b x : x=1 Ú x=2
TRUE "c x : x=5
FALSE G "c x : x=5
TRUE "c x : F $ c y : x=y
Sylvain Hallé 9

30. LTL-FO+
‘‘X and O must alternate’’
Sylvain Hallé 10

31. LTL-FO+
‘‘X and O must alternate’’
G( )
Sylvain Hallé 10

32. LTL-FO+
‘‘X and O must alternate’’
G ("Move/Player p : X (" p’ : p=p’))
Sylvain Hallé 10

33. LTL-FO+
‘‘X and O must alternate’’
G ("Move/Player p : X (" p’ : p=p’))
Sylvain Hallé 10

34. LTL-FO+
‘‘X and O must alternate’’
G ("Move/Player p : X ("Move/Player p’ : p=p’))
Sylvain Hallé 10

35. LTL-FO+
‘‘X and O must alternate’’
G ("Move/Player p : X ("Move/Player p’ : p=p’))
/
Sylvain Hallé 10

36. LTL-FO+
‘‘X and O must alternate’’
G ("Move/Player p : X ("Move/Player p’ : p=p’))
/
A trace of messages m that satisfies an interface contract j
is noted
m j
Sylvain Hallé 10

37. Contract compliance
If m / j , whose fault is it?
who·dun·it
A whodunit (for "Who['s] done it?") is a
complex, plot-driven variety of the
detective story in which the puzzle is the
main feature of interest. The reader is
provided with clues from which the identity
of the perpetrator of the crime may be
deduced before the solution is revealed in
the final pages of the book.
(Wikipedia)
Sylvain Hallé 11

38. Contract compliance
If m / j , whose fault is it?
who·dun·it
A whodunit (for "Who['s] done it?") is a
complex, plot-driven variety of the
detective story in which the puzzle is the
main feature of interest. The reader is
provided with clues from which the identity
of the perpetrator of the crime may be
deduced before the solution is revealed in
the final pages of the book.
(Wikipedia)
Sylvain Hallé 11

39. Contract compliance
Applications:
Which component does not implement the
standard correctly?
Which component should compensate
the others for the violation?
At runtime: which component should take
a different action to avoid a violation?
Sylvain Hallé 12

40. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
Sylvain Hallé 13

41. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
Sylvain Hallé 13

42. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
X
Sylvain Hallé 13

43. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
X X
O
Sylvain Hallé 13

44. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
X X X
O O X
Sylvain Hallé 13

45. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
X X X
O O X
Sylvain Hallé 13

46. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· . X and/ O mu
st alternate
1 m .m j
symbols
n’t put two
.
2. Ca
in sa me square
must be
ually, there
.
3. Event
a line of three O’s
X X X
O O X
Sylvain Hallé 13

47. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
Hypothesis #1
The sender of m is responsible for the contract violation
X X X
O O X
Sylvain Hallé 13

48. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
WAN TED
· m .m / j
Hypothesis #1
The sender of m is responsible for the contract violation
r ‘‘O’’
Playe g the
for violatin ntract
int erface co
X X X
O O X
Sylvain Hallé 13

49. Direct violation
Another example:
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O
X O X
O OX
X O
Sylvain Hallé 14

50. Direct violation
Another example:
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O
X O X
O OX
X O
Sylvain Hallé 14

51. Direct violation
Another example:
and O mu st alternate
1. X ls
X o symbo
n’t put tw
.
X X
2. Ca O O X
in sa me square
must be
ually, there
.
3. EveX tO
n
a li reeOO’s
ne of th X
O X
X O
X
X O
O X
X O X O
X O X
O X
X O X
O OX
X O
Sylvain Hallé 14

52. Direct violation
Another example:
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O
X O X
O OX
X O
Sylvain Hallé 14

53. Direct violation
Another example:
WANTED
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O Player ‘‘ X’’
for violating the
interface contrac
X O X
t
O OX
X O
Sylvain Hallé 14

54. Root violation
A message m is a root violation for a trace m if:
.
· m j and
· for any (infinite) suffix m’, we have m.m.m’ / j
Sylvain Hallé 15

55. Root violation
A message m is a root violation for a trace m if:
.
· m j and
· for any (infinite) suffix m’, we have m.m.m’ / j
Hypothesis #2:
The sender of m is responsible for the contract violation
Sylvain Hallé 15

56. Root violation
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O
X O X
O OX
X O
Sylvain Hallé 16

57. Root violation
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O
X O X
O OX
X O
Sylvain Hallé 16

58. Root violation
WANTED
X X X
O O X
X O X O X O X O X
O X O X O X O X
X X O X O Player ‘‘O’’
for violating the
interface contrac
X O X
t
O OX
X O
Sylvain Hallé 16

59. Observations
Sylvain Hallé 17

60. Observations
1. Root violations capture the fact that direct violations are
sometimes the result of a sequence of ‘‘forced moves’’
X O X O X O X O X X O X
O X O X O X O X O OX
X X O X O X O
Sylvain Hallé 17

61. Observations
1. Root violations capture the fact that direct violations are
sometimes the result of a sequence of ‘‘forced moves’’
X O X O X O X O X X O X
O X O X O X O X O OX
X X O X O X O
. WANTED WANTED
2. The faulty peer may not be the same
vs.
as in an ensuing direct violation
Sylvain Hallé 17

62. Observations
1. Root violations capture the fact that direct violations are
sometimes the result of a sequence of ‘‘forced moves’’
X O X O X O X O X X O X
O X O X O X O X O OX
X X O X O X O
. WANTED WANTED
2. The faulty peer may not be the same
vs.
as in an ensuing direct violation
.
3. The interface contract is not contradictory
in itself: a root violation depends on the
actual course of actions taken
Sylvain Hallé 17

63. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
Sylvain Hallé 18

64. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
a b
a b
b
a
Sylvain Hallé 18

65. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
a b
a b
b
a
Sylvain Hallé 18

66. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
.
3. Read m by keeping pointers to states of M
.
a b
a b
b
a
Sylvain Hallé 18

67. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
.
3. Read m by keeping pointers to states of M
.
a b
a b
m=a a
b
Sylvain Hallé 18

68. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
.
3. Read m by keeping pointers to states of M
.
a b
a b
m=ab a
b
Sylvain Hallé 18

69. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
.
3. Read m by keeping pointers to states of M:
discard any pointer to
.
a b
a b
m=ab a
b
Sylvain Hallé 18

70. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
.
3. Read m by keeping pointers to states of M:
discard any pointer to
.
a b
a b
m=aba a
b
Sylvain Hallé 18

71. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
1. Create the Büchi automaton M equivalent to j
.
2. Label each state based on language emptiness ( )
or not ( )
.
3. Read m by keeping pointers to states of M:
discard any pointer to
.
a b
4. A message is a root violation if
a
no pointer is left b
m=aba a
b
Sylvain Hallé 18

72. How to find root violations?
Problem:
· Designed for LTL
a b
a b
b
a
Sylvain Hallé 19

73. How to find root violations?
Problem:
· Designed for LTL
.
· With LTL-FO+, M is infinite
a b
a b
b
a
Sylvain Hallé 19

74. How to find root violations?
Solution #2
Conversion to LTL
1. Bound the domains for each path expression
.
2. Convert quantifiers into equivalent expressions
If f(_, a/b) Í {1,2} , then
"a/b x : F $ a/b y : x=y becomes
( F $ a/b y : 1=y ) Ù ( F $ a/b y : 2=y )
...and so on
Sylvain Hallé 20

75. How to find root violations?
Solution #2
Conversion to LTL
3. The formula is now pure LTL; use solution #1
OR
4. Send messages one by one to an LTL model checker
Sylvain Hallé 20

76. How to find root violations?
Solution #2
Conversion to LTL
3. The formula is now pure LTL; use solution #1
OR
4. Send messages one by one to an LTL model checker
m1 j ?
Sylvain Hallé 20

77. How to find root violations?
Solution #2
Conversion to LTL
3. The formula is now pure LTL; use solution #1
OR
4. Send messages one by one to an LTL model checker
m1 j ?
m1 m2 j ?
Sylvain Hallé 20

78. How to find root violations?
Solution #2
Conversion to LTL
3. The formula is now pure LTL; use solution #1
OR
4. Send messages one by one to an LTL model checker
m1 j ?
m1 m2 j ?
m1 m2 m3 j ?
Sylvain Hallé 20

79. How to find root violations?
Solution #2
Conversion to LTL
3. The formula is now pure LTL; use solution #1
OR
4. Send messages one by one to an LTL model checker
m1 j ?
m1 m2 j ?
m1 m2 m3 j ?
The first message that causes the validation to fail is
a root violation
Sylvain Hallé 20

80. How to find root violations?
Problem:
· Requires bounded data domains
· Exponential blow-up of formula
· Non-incremental process
Sylvain Hallé 21

81. Proposed solution
Exploit an on-the-fly runtime monitoring algorithm for linear
temporal logic
.
Sylvain Hallé 22

82. Proposed solution
Exploit an on-the-fly runtime monitoring algorithm for linear
temporal logic
.
1. Monitor state = set of LTL-FO+ formulas
s
Sylvain Hallé 22

83. Proposed solution
Exploit an on-the-fly runtime monitoring algorithm for linear
temporal logic
.
1. Monitor state = set of LTL-FO+ formulas
2. Upon each new message: update state according to
transformation rules
s
Sylvain Hallé 22

84. Proposed solution
Exploit an on-the-fly runtime monitoring algorithm for linear
temporal logic
.
1. Monitor state = set of LTL-FO+ formulas
2. Upon each new message: update state according to
transformation rules
s
s’
Sylvain Hallé 22

85. Proposed solution
Exploit an on-the-fly runtime monitoring algorithm for linear
temporal logic
.
1. Monitor state = set of LTL-FO+ formulas
2. Upon each new message: update state according to
transformation rules
3. Compute an outcome function on resulting state
to decide if contract is violated
s
s’
Sylvain Hallé 22

86. Proposed solution
Exploit an on-the-fly runtime monitoring algorithm for linear
temporal logic
.
1. Monitor state = set of LTL-FO+ formulas
2. Upon each new message: update state according to
transformation rules
3. Compute an outcome function on resulting state
to decide if contract is violated
s’
Sylvain Hallé 22

87. Runtime monitoring
Algorithm overview:
1. An LTL formula is decomposed into nodes of the form
sub-formulas that sub-formulas that must
must be true now be true in the next state
Example:
Sylvain Hallé 23

88. Runtime monitoring
2. Negations pushed inside (classical identities +
dual of U = V)
3. At the leaves, G contains atoms + negations of atoms:
we evaluate them
Verdict:
! All leaves contain FALSE: formula is false
! A leaf is empty: formula is true
! Otherwise:
4. Next event: D copied into G and we continue
Sylvain Hallé 24

89. Runtime monitoring
Example: G (a ® X Øa)
Sylvain Hallé 25

90. Runtime monitoring
Example: G (a ® X Øa)
G (a ® X Øa) ’
a ® X Øa ’ G (a ® X Øa)
Øa ’ G (a ® X Øa) a, X Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
Sylvain Hallé 25

91. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
Sylvain Hallé 25

92. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

93. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

94. Runtime monitoring
Example: G (a ® X Øa)
a ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

95. Runtime monitoring
Example: G (a ® X Øa)
’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

96. Runtime monitoring
Example: G (a ® X Øa)
G (a ® X Øa), Øa ’
’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

97. Runtime monitoring
Example: G (a ® X Øa)
G (a ® X Øa), Øa ’
a ® X b, b ’ G (a ® X Øa)
Øa ’ G (a ® X Øa) a, X Øa, Øa ’ G (a ® X Øa)
a, Øa ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

98. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a, Øa ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

99. Runtime monitoring
Example: G (a ® X Øa)
A variable and its negation
can never be true at the same
time
Øa ’ G (a ® X Øa)
a, Øa ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

100. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a, Øa ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25

101. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
s=a
Sylvain Hallé 25

102. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
s = aa
Sylvain Hallé 25

103. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
s = aa
Sylvain Hallé 25

104. Runtime monitoring
Example: G (a ® X Øa)
No way to extend the trace:
formula is false, i.e. message c
is a direct violation of the formula
s = aa
Sylvain Hallé 25

105. Detecting direct violations
By construction (Gerth et al., PSTV 1995):
Let N = be a monitor node resulting from the
processing of a message m. The message is a direct
violation of the conditions in N if and only if it contains
p Ù Øp
for some proposition p.
Sylvain Hallé 26

106. Detecting direct violations
By construction (Gerth et al., PSTV 1995):
Let N = be a monitor node resulting from the
processing of a message m. The message is a direct
violation of the conditions in N if and only if it contains
p Ù Øp
for some proposition p.
Consequence
m is a direct violation if this happens for all leaf nodes
Sylvain Hallé 26

107. Detecting root violations
Theorem
Let N = be a monitor node resulting from the
processing of a message m. The message is a root
violation of the conditions in N if and only if the formula
( Ù G ) Ù X( Ù D )
is unsatisfiable. (See paper for the proof!)
Sylvain Hallé 27

108. Detecting root violations
Theorem
Let N = be a monitor node resulting from the
processing of a message m. The message is a root
violation of the conditions in N if and only if the formula
( Ù G ) Ù X( Ù D )
is unsatisfiable. (See paper for the proof!)
Consequence
m is a root violation if this happens for all leaf nodes
Sylvain Hallé 27

109. Intuition
1. In the algorithm, each leaf node represents a possible set of
conditions for a valid extension of the current trace
sub-formulas that sub-formulas that must
must be true now be true in the next state
2. If the conditions are contradictory, no trace extension can
ever satisfy them
.
Ù
3. The formula p Ù Øp is a special case of ( G ) Ù X( Ù D),
where the contradiction occurs in the current message
.
4. Detection of root violations reduces to satisfiability solving of
some set of LTL formulas
Sylvain Hallé 28

110. Adding first-order quantifiers
Decomposition rules can be added to deal with LTL-FO+; the
definition of root violation does not change
1. Atoms become equality tests
(and vice versa)
2. Decomposition rules for quantifiers
Sylvain Hallé 29

111. A workflow for root violation detection
Sylvain Hallé 30

112. A workflow for root violation detection
1 1
... n n
}
Leaf nodes from current
monitor state
Sylvain Hallé 30

113. A workflow for root violation detection
1 1
... n n
}
m
Incoming
message
Sylvain Hallé 30

114. A workflow for root violation detection
1 1
... n n
}
m UPDATE
Monitor
update function
Sylvain Hallé 30

115. A workflow for root violation detection
1 1
... n n
} } 1
' '
1
...
m UPDATE
' '
k k
New leaf nodes
Sylvain Hallé 30

116. A workflow for root violation detection
Node sent to LTL-FO+
1 1
... n n satisfiability solver
} } '
1
'
1 S
...
m UPDATE
' '
k k
Sylvain Hallé 30

117. A workflow for root violation detection
... Kept if
1 1 n n satisfiable
} } '
1
'
1 S
SAT
1
' '
1
...
m UPDATE
' '
k k
Sylvain Hallé 30

118. A workflow for root violation detection
1 1
... n n
} } '
1
'
1 S
UNSAT
SAT '
1
'
1
...
m UPDATE X Deleted if not
' '
k k
Sylvain Hallé 30

119. A workflow for root violation detection
1 1
... n n
} } '
1
'
1 S
UNSAT
SAT '
1
'
1
...
m UPDATE X
UNSAT
'
k
'
k S SAT
'
k
'
k
Repeat for every node
Sylvain Hallé 30

120. A workflow for root violation detection
1 1
... n n
} } '
1
'
1 S
UNSAT
SAT '
1
'
1
...
m UPDATE X
UNSAT
'
k
'
k S SAT
'
k
'
k
New monitor
nodes
Sylvain Hallé 30

121. A workflow for root violation detection
1 1
... n n
} } '
1
'
1 S
UNSAT
SAT '
1
'
1
...
m UPDATE X
UNSAT
'
k
'
k S SAT
'
k
'
k
Declare root violation if no
node remains after pruning
Sylvain Hallé 30

122. Experimental setup
BeepBeep (Hallé & Villemaire, 2011) used as the
LTL-FO+ runtime monitor
TSPASS (Ludwig & Hustadt, 2010) used as the
S
temporal satisfiability solver
100 randomly-generated traces of shopping cart
transactions
Validation of the shopping cart contract
Sylvain Hallé 31

123. Experimental results
Experiment 1: overhead incurred by use of a solver
Solver time:
40 13 ms / message
Number of traces
30
20
10
0
<1 1-2 2-3 3-4 >4
Overhead
Sylvain Hallé 32

124. Experimental results
Experiment 2: difference (in messages) between root and direct
violation
80
Number of traces
60 Violation detected
‘‘in advance’’: 18%
40 less messages consumed
20
0
0 1-5 6-10 11-15 16-20
Length difference
Sylvain Hallé 33

125. Future work
The concept of violation is a parameterized one:
s
s’
Sylvain Hallé 34

126. Future work
The concept of violation is a parameterized one:
Call an error when
the current trace cannot be
extended by at least
n suffixes with at least
k messages
s
s’
Sylvain Hallé 34

127. Future work
The concept of violation is a parameterized one:
k = ‘‘lookahead’’
n = ‘‘degree of freedom’’
Call an error when
the current trace cannot be
extended by at least
n suffixes with at least
k messages
s
s’
Sylvain Hallé 34

128. Future work
The concept of violation is a parameterized one:
k = ‘‘lookahead’’
n = ‘‘degree of freedom’’
Call an error when
· Direct violation the current trace cannot be
extended by at least
n=1, k=1 n suffixes with at least
k messages
s
s’
Sylvain Hallé 34

129. Future work
The concept of violation is a parameterized one:
k = ‘‘lookahead’’
n = ‘‘degree of freedom’’
Call an error when
· Direct violation the current trace cannot be
extended by at least
n=1, k=1 n suffixes with at least
k messages
· Root cause s
n=1, k=¥
s’
Sylvain Hallé 34

130. Take-home points
1. The peer responsible for an interface contract violation may
not cause it directly
.
2. A root violation occurs when no infinite extension of the
current transaction can ever fulfill an interface contract
.
3. Using LTL-FO+ as the specification language, reduction
to the propositional case results in an infinite search problem
.
4. Leveraging on a runtime monitoring algorithm, root cause
detection reduces to satisfiability solving
.
5. An experimental setup can detect direct
violations ahead of time with reasonable
overhead
Sylvain Hallé 35