Requirements on message-based interactions can be formalized as an interface contract that specifies constraints on the sequence of possible messages that can be exchanged by multiple parties. At runtime, each peer can monitor incoming messages and check that the contract is correctly being followed by their respective senders. We introduce cooperative runtime monitoring, where a recipient “delegates” its monitoring task to the sender, which is required to provide evidence that the message it sends complies with the contract. In turn, this evidence can be quickly checked by the recipient, which is then guaranteed of the sender’s compliance to the contract without doing the monitoring computation by itself. A particular application of this concept is shown on web services, where service providers can monitor and enforce contract compliance of third-party clients at a small cost on the server side, while avoiding to certify or digitally sign them.
5. Context
The
Server
A
The
Client
Sylvain Hallé 2
6. Context
The Request
Server message
A
The
Client
Sylvain Hallé 2
7. Context
The
Server
A
B
The
Client
Sylvain Hallé 2
8. Context
The
Server
A
Response
message B
The
Client
Sylvain Hallé 2
9. Context
Alphabet (A)
Set of possible messages
Sylvain Hallé 3
10. Context
Alphabet (A)
Set of possible messages
Trace (A*)
Sequence of messages
Sylvain Hallé 3
11. Context
Alphabet (A)
Set of possible messages
Trace (A*)
Sequence of messages
State
Abstraction of a trace
Sylvain Hallé 3
12. Context
Transition function (d
)
d
Sylvain Hallé 3
13. Context
Transition function (d
)
d
A
Sylvain Hallé 3
14. Context
Transition function (d
)
d
A s
S
Sylvain Hallé 3
15. Context
Transition function (d
)
d s’
A s
S
Sylvain Hallé 3
16. Context
Transition function (d
)
d s’
Æ
A s
S
Sylvain Hallé 3
17. Context
Transition function (d
)
dS ®
:A´ S
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
d s’
Æ
A s
S
Sylvain Hallé 3
18. Context
Transition function (d
)
dS ®
:A´ S
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
A s
S
Sylvain Hallé 3
19. Context
Transition function (d
)
dS ®
:A´ S
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
k n)= T
(a0a1...a
A s
S
Sylvain Hallé 3
20. Context
Transition function (d
)
dS ®
:A´ S
Û
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
k n)= T
(a0a1...a
A s
S
Sylvain Hallé 3
21. Context
Transition function (d
)
dS ®
:A´ S
Û
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
k n)= T
(a0a1...a
A s
S d a n) ¹
(a0a1 ... Æ
Sylvain Hallé 3
22. A general framework
Server
A Message
Client
Interface contract
Sylvain Hallé 4
23. A general framework
Iterator
class Method
A call
Java
program
Two calls of the next() method must be
separated by at least one occurrence of
hasNext().
Sylvain Hallé 4
24. A general framework
web XML
service A message
Ajax web
client
If CartClear is invoked, no CartModify or
CartRemove can occur before a new
CartAdd.
Sylvain Hallé 5
25. Contract violations
What happens when the contract is violated?
- Error messages
- Non-sensical data returned
- Compensation mechanisms
- Wasted processing time
- Security breaches
- Etc.
Sylvain Hallé 6
27. Current solutions
1. A priori certification
A trustworthy authority
assesses the client’s
compliance to the contract...
Testing, static
verification
etc.
Sylvain Hallé 8
28. Current solutions
1. A priori certification
A trustworthy authority
assesses the client’s
compliance to the contract...
...and grants a digital
certificate
Sylvain Hallé 8
29. Current solutions
1. A priori certification
A+
The service needs a certificate to
start an exchange with a client
Sylvain Hallé 8
30. Current solutions
1. A priori certification
A+
The service needs a certificate to
start an exchange with a client
Example: iPhone app certification
Sylvain Hallé 8
31. Current solutions
1. A priori certification
Z+
Problem: the client can change after
certification
iPhone jailbreaking,
Javascript prototype hijacking, ...
Sylvain Hallé 8
32. Current solutions
2. Server-side Runtime
Monitoring
A separate process checks
each incoming message...
A
Sylvain Hallé 9
33. Current solutions
2. Server-side Runtime
Monitoring
A separate process checks
A each incoming message...
The message is relayed to the application
proper when it complies with the contract
Sylvain Hallé 9
34. Current solutions
2. Server-side Runtime
Monitoring
A separate process checks
each incoming message...
...and is discarded when it violates the
contract
Sylvain Hallé 9
35. Current solutions
2. Server-side Runtime
Monitoring
Problem: computational load on the server
side
Sylvain Hallé 9
36. Current solutions
3. Client-side Runtime
Monitoring
Each client has a separate
process that validates its
messages before sending them
A
Sylvain Hallé 10
37. Current solutions
3. Client-side Runtime
Monitoring
Z
Z
Z
Problem: server has no guarantee that
monitoring actually takes place
Sylvain Hallé 10
38. Goal
Processing savings of
client-side monitoring
Guarantees of server-side
monitoring
Sylvain Hallé 11
39. Goal
COOPERATIVE
RUNTIME MONITORING
Processing savings of
client-side monitoring
Guarantees of server-side
monitoring
Sylvain Hallé 11
48. Cooperative runtime monitoring
Both the server- and client-
side monitors maintain the
current state of the message
exchange
s
s
Sylvain Hallé 13
49. Cooperative runtime monitoring
From its current state (s) and
new message (A), the client-
side monitor computes (g )...
A
Sylvain Hallé 13
50. Cooperative runtime monitoring
From its current state (s) and
new message (A), the client-
side monitor computes (g )...
s, s’,
A)
g=
( ()
s’ The new contract state
A ‘‘proof’’ that A is a valid extension
of the message exchange
Sylvain Hallé 13
52. Cooperative runtime monitoring
From its current state (s),
incoming message (A) and
proof ( ), the server-side
monitor computes (m and n)...
Sylvain Hallé 13
53. Cooperative runtime monitoring
From its current state (s),
incoming message (A) and
proof ( ), the server-side
monitor computes (m and n)...
A,=
m T/F
()
n s’
s,
(= )
T/F If the proof is consistent with the
accompanying message
s’ The new contract state
Sylvain Hallé 13
55. Cooperative runtime monitoring
Both sides agree on the new current state (s’)
The client computes
s’ it from s and A
s’
Sylvain Hallé 14
56. Cooperative runtime monitoring
Both sides agree on the new current state (s’)
The client computes
s’ it from s and A
s’
The server computes
it from s and
Sylvain Hallé 14
57. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
Sylvain Hallé 15
58. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s, then for
any , either m F or n ?
A,=s,=
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15
59. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s, then for
any , either m F or n ?
A,=s,=
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15
60. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s, then for
any , either m F or n ?
A,=s,=
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15
61. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s (d Æ
(s,A) = ),
A,=s,=
then for any , either m F or n ?
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15
62. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s (d Æ
(s,A) = ),
A,=s,=
then for any , either m F or n ?
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
s , s’, ( )
A)
g =, m T and n s’
( () , = ( = A s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15
63. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s (d Æ
(s,A) = ),
A,=s,=
then for any , either m F or n ?
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
s , s’, ( )
A)
g =, m T and n s’
( () , = ( = A s, )
3. Checking the proof must be easy (i.e. polynomial)
Þ be in NP
mmust
and n
Sylvain Hallé 15
64. Expressing an interface contract
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 ØW c
(q Ú
t) TRUE
Gerth, Peled, Vardi, Wolper (PSTV 1995): on-the-fly runtime
monitoring algorithm for LTL
Sylvain Hallé 16
65. Classical LTL 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
Sylvain Hallé 17
66. Classical LTL 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é 17
67. Classical LTL runtime monitoring
2. Negations pushed inside (classical identities +
dual of U = V)
3. At the leaves, G atoms + negations of atoms:
contains
we evaluate them
Verdict:
! All leaves contain FALSE: formula is false
! A leaf is empty: formula is true
! Otherwise:
4. Next event: D into G continue
copied and we
Sylvain Hallé 18
68. Classical LTL runtime monitoring
Example: G
G (p Ù F s))
(X q Ú
1
2
X
p
F1 F2
p
Sylvain Hallé 19
69. Classical LTL runtime monitoring
Example: G
G (p Ù F s))
(X q Ú
If p is true and s is false in the 1
current message m, then...
2
X
p
p
F1 F2
p
s p
Sylvain Hallé 20
70. Intuition for g
s
1. This algorithm computes G
d s’
(s,A) =
1
2
X
p
p
s’ F1 F2
p
s p
s’
Sylvain Hallé 21
71. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21
72. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21
73. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21
74. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù
,Ú
1 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21
75. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù
,Ú
1, X 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21
76. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú
1, X, 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21
77. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú1, X, 2
X
{q, G (p Ù F s))}
(X q Ú
p
p
F1 F2
p
s p
Sylvain Hallé 21
78. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú1, X, 2
X
{q, G (p Ù F s))}
(X q Ú
p
+ p
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú F1 F2
p
s p
Sylvain Hallé 21
79. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú1, X, 2
X
{q, G (p Ù F s))}
(X q Ú
p
+ p
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú F1 F2
p
3. The combination gives us
s p
s , s’,
g= A)
( ()
Sylvain Hallé 21
80. Intuition for m
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
Given a message (A) and a proof ( ), one can check that the
atoms in the paths are indeed true in the message...
= G, Ùp,Ú, X,
1
{q, G (p Ù F s))}
(X q Ú Is p true
in A?
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
...this computes
m ()A,
Sylvain Hallé 22
81. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù F s))
(X q Ú
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
82. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù F s))
G (X q Ú
= G Ùp
G, , Ú
, X,
1
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
83. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù F s))
(X q Ú
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
84. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ùs))
ÙF
(X q Ú
= G, Ù
Ùp,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
85. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
,qÚ
G (p Ù F s))
(X
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
86. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
, qÚ
G (p Ù F s))
(X Ú
= ,Ú
G, Ù pÚ1, X,
1
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
87. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
,q
G (p Ù
(X
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
88. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
,q
G (p ÙX
(X
= G, Ù p
,Ú1, X
X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
89. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù
(X q q
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
90. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
p q
= G, Ùp,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
91. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
q
= G, Ù ,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23
92. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
q
= G, Ù,Ú , X,
1
...if the operation comes to
{q, G (p Ù F s))}
(X q Ú
an end, we accept the leaf
+
G, Ù p
,Ú
given in as the resulting
2, F2,
{F q, G (p Ù F s))}
(X q Ú end state s’
...this computes
n s’
s,
(= )
Sylvain Hallé 23
93. What about complexity?
number of witnesses < total number of leaves
<
s,
(n <
() < (g)
) (s,A)
Does not expand
‘‘dead-end’’ branches
Sylvain Hallé 24
94. What about complexity?
number of witnesses < total number of leaves
<
s,
(n <
() < (g)
) (s,A)
number of witnesses total number of leaves
(n s,
() ) (g)(s,A)
Sylvain Hallé 24
95. What about complexity?
number of witnesses < total number of leaves
<
s,
(n <
() < (g)
) (s,A)
number of witnesses total number of leaves
(n s,
() ) (g)(s,A)
check the proof compute the proof
Þ
Sylvain Hallé
{
Non-branching LTL
No gain...
Solution: restrict LTL to fragment that produces at most one
witness at every step
24
104. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Theorem: a non-branching LTL formula produces a proof ( )
linear in the length of the interface contract (see the paper!)
Sylvain Hallé 25
105. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Theorem: a non-branching LTL formula produces a proof ( )
linear in the length of the interface contract (see the paper!)
Non-branching LTL contracts can be efficiently enforced
Þ
through cooperative runtime monitoring
Sylvain Hallé 25
122. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
Sylvain Hallé 28
123. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
.
Sylvain Hallé 28
124. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
..
3. For a fragment of Linear Temporal Logic, empirical tests
show that 90% of the work can be outsourced to the client...
Sylvain Hallé 28
125. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
..
3. For a fragment of Linear Temporal Logic, empirical tests
show that 90% of the work can be outsourced to the client...
.
4. ...while preserving the same guarantees as with
server-side monitoring
Sylvain Hallé 28
126. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
..
3. For a fragment of Linear Temporal Logic, empirical tests
show that 90% of the work can be outsourced to the client...
.
4. ...while preserving the same guarantees as with
server-side monitoring
.
5. This is a 3D problem: guarantees, computational
load and expressiveness can be modulated
Sylvain Hallé 28