The document describes a method for automatically simulating SOAP web services from temporal logic specifications. It discusses how SOAP web services use XML messages in requests and responses to form transactions, but not all message sequences are valid. It presents challenges in creating a realistic stub service that follows constraints on valid sequences and parameter values. Current solutions involve hard-coding responses, but the document proposes using Linear Temporal Logic with First-Order quantifiers (LTL-FO+) to specify valid behavior, and decomposing the specification into a tree to guide automatic message generation. This allows producing response sequences directly from the logical constraints.

1. Model-Based Simulation of SOAP Web
Services From Temporal Logic Specifications
Sylvain Hallé
Université du Québec à Chicoutimi
CANADA
Fonds de recherche
sur la nature
et les technologies NSERC
CRSNG
Sylvain Hallé

2. A motivating scenario
Sylvain Hallé

3. A motivating scenario
$
Sylvain Hallé

4. A motivating scenario
?
Sylvain Hallé

5. A motivating scenario
?
Sylvain Hallé

6. A motivating scenario
!
Sylvain Hallé

7. A motivating scenario
?
!
Sylvain Hallé

8. A motivating scenario
Interaction
?
!
Web service Web client
Sylvain Hallé

9. A motivating scenario
Sylvain Hallé

10. A motivating scenario
We want to do, as automatically as possible...
DRIVER STUB
...impersonate the client, send ...impersonate the service,
test sequences to the service generate responses to the client
?
Check if service does what ? closed
Environment
we expect/understand Þ model checking possible
Sylvain Hallé

11. A motivating scenario
Some reasons for creating a stub:
· a cilent under development,
Test
without performing real actions on STUB
the actual service
Provide a closed environment for model checking
·
Alternative to sandboxes: the stub's responses are
·
under the developer's control
Sylvain Hallé

12. A SOAP web service
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
<ItemID>789</ItemID>
...
</Items>
</CartAdd>
Request message in XML format:
· elements
Nested
· occurrences of the same element name
Many
· structure
Flexible
Sylvain Hallé

13. A SOAP web service
Requests and
responses form a
transaction...
Sylvain Hallé

14. A SOAP web service
Requests and
<ItemSearch>
<Term>abc</Term>
responses form a
</ItemSearch>
transaction...
Sylvain Hallé

15. A SOAP web service
Requests and
<ItemSearch>
<Term>abc</Term>
responses form a
</ItemSearch>
transaction...
<ItemSearchResponse>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</ItemSearchResponse>
Sylvain Hallé

16. A SOAP web service
Requests and
<ItemSearch>
<Term>abc</Term>
responses form a
</ItemSearch>
transaction...
<ItemSearchResponse>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</ItemSearchResponse>
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
<ItemID>789</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

17. A SOAP web service
Requests and
<ItemSearch>
<Term>abc</Term>
responses form a
</ItemSearch>
transaction...
<ItemSearchResponse>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</ItemSearchResponse>
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
<ItemID>789</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

18. A SOAP web service
Requests and
<ItemSearch>
<Term>abc</Term>
responses form a
</ItemSearch>
transaction...
<ItemSearchResponse>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...but not all
...
</Items>
</ItemSearchResponse> sequences are
valid!
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
<ItemID>789</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

19. A SOAP web service
1. Cart
<ItemSearch>
<Term>abc</Term>
operations must
</ItemSearch>
begin with a
<ItemSearchResponse>
CartCreate
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
message
...
</Items>
</ItemSearchResponse>
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
<ItemID>789</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

20. A SOAP web service
Sylvain Hallé

21. A SOAP web service
<CartCreate>
</CartCreate>
Sylvain Hallé

22. A SOAP web service
<CartCreate>
</CartCreate>
<CartCreateResponse>
<CartID>ID123</CartID>
</CartCreateResponse>
Sylvain Hallé

23. A SOAP web service
<CartCreate>
</CartCreate>
<CartCreateResponse>
<CartID>ID123</CartID>
</CartCreateResponse>
<CartAdd>
<CartID>ID456</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

24. A SOAP web service
<CartCreate>
</CartCreate>
<CartCreateResponse>
<CartID>ID123</CartID>
</CartCreateResponse>
<CartAdd>
<CartID>ID456</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

25. A SOAP web service
2. Once a cart is
<CartCreate>
created, the
</CartCreate>
same CartID
<CartCreateResponse>
<CartID>ID123</CartID>
must be passed
</CartCreateResponse>
in all requests
<CartAdd>
<CartID>ID456</CartID>
and responses
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

26. A SOAP web service
<CartCreate>
</CartCreate>
<CartCreateResponse>
<CartID>ID123</CartID>
</CartCreateResponse>
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
Sylvain Hallé

27. A SOAP web service
<CartCreate>
</CartCreate>
<CartCreateResponse>
<CartID>ID123</CartID>
</CartCreateResponse>
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
...
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>456</ItemID>
</Items>
</CartAdd>
Sylvain Hallé

28. A SOAP web service
<CartCreate>
</CartCreate>
<CartCreateResponse>
<CartID>ID123</CartID>
</CartCreateResponse>
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
...
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>456</ItemID>
</Items>
</CartAdd>
Sylvain Hallé

29. A SOAP web service
3. The same item
<CartCreate>
cannot be added
</CartCreate>
via CartAdd
<CartCreateResponse>
<CartID>ID123</CartID>
twice to
</CartCreateResponse>
the same
<CartAdd>
<CartID>ID123</CartID>
shopping cart
<Items>
<ItemID>123</ItemID>
<ItemID>456</ItemID>
...
</Items>
</CartAdd>
...
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>456</ItemID>
</Items>
</CartAdd>
Sylvain Hallé

30. Challenge
The real service's behaviour follows constraints on:
1. Sequences of operations only
2. Parameter values only
3. Both at the same time
How can we create a realistic stub that
follows these constraints?
Sylvain Hallé

31. Current solutions
: create mock web services
Sylvain Hallé

32. Current solutions
Problem
.
Responses are
hard-coded
messages
Sylvain Hallé

33. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
Problem
.
Responses are
hard-coded
messages
Sylvain Hallé

34. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
Problem
.
Responses are
hard-coded
messages
Sylvain Hallé

35. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
<CartAddResponse>
Problem
<CartID>ID123</CartID>
.
<Items>
<ItemID>123</ItemID>
</Items>
Responses are
</CartAdd>
hard-coded
messages
Sylvain Hallé

36. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
<CartAddResponse>
Problem
<CartID>ID123</CartID>
.
<Items>
<ItemID>123</ItemID>
</Items>
Responses are
</CartAdd>
hard-coded
<CartAdd>
<CartID>ID123</CartID>
messages
<Items>
<ItemID>456</ItemID>
</Items>
</CartAdd>
Sylvain Hallé

37. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
<CartAddResponse>
Problem
<CartID>ID123</CartID>
.
<Items>
<ItemID>123</ItemID>
</Items>
Responses are
</CartAdd>
hard-coded
<CartAdd>
<CartID>ID123</CartID>
messages
<Items>
<ItemID>456</ItemID>
</Items>
</CartAdd>
Sylvain Hallé

38. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
<CartAddResponse>
Problem
<CartID>ID123</CartID>
.
<Items>
<ItemID>123</ItemID>
</Items>
Responses are
</CartAdd>
hard-coded
<CartAdd>
<CartID>ID123</CartID>
messages
<Items>
<ItemID>456</ItemID>
</Items>
</CartAdd>
<CartAddResponse>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
Sylvain Hallé

39. Current solutions
<CartAdd>
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items>
</CartAdd>
<CartAddResponse>
Problem
<CartID>ID123</CartID>
.
<Items>
<ItemID>123</ItemID>
</Items>
Responses are
</CartAdd>
hard-coded
<CartAdd>
<CartID>ID123</CartID>
messages: for
<Items>
<ItemID>456</ItemID>
</Items>
each request
</CartAdd>
type, same
<CartAddResponse>
?!? response every
<CartID>ID123</CartID>
<Items>
<ItemID>123</ItemID>
</Items> time!
</CartAdd>
Sylvain Hallé

40. Current solutions
Other way:
program a
realistic stub in a
programming
language
Sylvain Hallé

41. Current solutions
struct m_cart;
if (m_cart.item
add(m_item.id)
else
return XML("<
Other way:
program a
realistic stub in a
programming
language
Sylvain Hallé

42. Specification of service behaviour
LTL-FO+: extension of LTL with quantifiers on message
parameters (Hallé & Villemaire, IEEE Trans. on Services
Computing 2011)
Can be used to express constraints on sequences of messages
and their values
For example, constraint 2:
.
G ("
CartCreateResponse/CartID/x : .
X G (" CartAddResponse/CartID/y : x=y))
.
...detailed semantics in the paper!
Sylvain Hallé

43. Problem
Using LTL-FO+ as the specification language, producing a web
service stub becomes an application of LTL-FO+ satisfiability
solving
Given...
A pre-existing trace of requests
·
· LTL-FO+ formula
An
Produce:
· extension of the trace (by one message) that
An
satisfies the formula
Sylvain Hallé

44. Initial solution*
A model checker can find a counter-example trace of a formula,
if there is one
.
Create a Kripke structure whose first n transitions are
unique (and correspond to the pre-existing trace)
.
Don't give any constraints for the (n+1)-th state
.
Run the model checker on that system with the
negated specification
.
The counter-example found gives us a possible
extension of the existing trace
* S. Hallé, WS-FM 2010
Sylvain Hallé

45. New solution
Don't rely on external tools, devise an algorithm to produce
sequences directly from a formula
Interpret assertions on sequences of messages...
...as directions to produce sequences of messages
The trick: decompose the formula into a tree of nodes
sub-formulas that sub-formulas that must
must be true now be true next time
= conditions on = conditions on
the current message the remainder of the
to generate transaction
Sylvain Hallé

46. Decomposition rules
Decomposition rules for some operators:
Sylvain Hallé

47. Decomposition rules
Decomposition rules for some operators:
"j must hold
in every message"
Sylvain Hallé

48. Decomposition rules
Decomposition rules for some operators:
"j must hold
in every message"
Create a message that
fulfills j
Sylvain Hallé

49. Decomposition rules
Decomposition rules for some operators:
"j must hold
in every message"
Create a message that And next time, make
fulfills j sure that G j
holds
Sylvain Hallé

50. Decomposition rules
Decomposition rules for some operators:
"j must hold "j must hold
in every message" in the next
message"
Create a message that And next time, make
fulfills j sure that G j
holds
Sylvain Hallé

51. Decomposition rules
Decomposition rules for some operators:
"j must hold "j must hold
in every message" in the next
message"
Create a message that And next time, make
fulfills j sure that G j
holds (No condition on
current message)
Sylvain Hallé

52. Decomposition rules
Decomposition rules for some operators:
"j must hold "j must hold
in every message" in the next
message"
Create a message that And next time, make
fulfills j sure that G j
holds (No condition on Next time, make
current message) sure that jholds
Sylvain Hallé

53. Decomposition rules
Multiple branches = alternatives
Sylvain Hallé

54. Decomposition rules
Multiple branches = alternatives
"j must hold
eventually"
In the current
message... In a future
message...
Sylvain Hallé

55. Decomposition rules
Example: G (a ®
X b)
G (a ®
X b) ?
a ®®
X b ?b)
G (a X
Ø ®a, X b ?b)
a ?b)
G (a X G (a ®
X
a ?b), b
G (a ®
X
Sylvain Hallé

56. Decomposition rules
Example: G (a ®
X b)
G (a ®
X b) ?
a ®®
X b ?b)
G (a X
Ø ®a, X b ?b)
a ?b)
G (a X G (a ®
X
- Create a message that a ?b), b
G (a ®
X
fulfills Ø
a
- Next time G (a ® X b)
must hold
Sylvain Hallé

57. Decomposition rules
Example: G (a ®
X b)
G (a ®
X b) ?
a ®®
X b ?b)
G (a X
- Create a message that
Ø ®a, X b ?b)
a ?b)
G (a X G (a ® fulfills a
X
- Next time G (a ® X b)
and b must hold
- Create a message that a ?b), b
G (a ®
X
fulfills Ø
a
- Next time G (a ® X b)
must hold
Sylvain Hallé

58. Decomposition rules
Once we exhaust the decomposition rules to apply...
- Create a message that
a ?b)
G (a X
Ø ® fulfills a
- Next time G (a ® X b)
and b must hold
- Create a message that a ?b), b
G (a ®
X
fulfills Ø
a
- Next time G (a ® X b)
must hold
Sylvain Hallé

59. Decomposition rules
Once we exhaust the decomposition rules to apply...
...we pick (arbitrarily) one of the alternatives
- Create a message that
fulfills a
- Next time G (a ® X b)
and b must hold
a ?b), b
G (a ®
X
Sylvain Hallé

60. Decomposition rules
Once we exhaust the decomposition rules to apply...
...we pick (arbitrarily) one of the alternatives and
create a message based on the conditions
- Create a message that
fulfills a
- Next time G (a ® X b)
and b must hold
a ?b), b
G (a ®
X
a
Sylvain Hallé

61. Decomposition rules
Once we exhaust the decomposition rules to apply...
...we pick (arbitrarily) one of the alternatives and
create a message based on the conditions
The right-hand side
G (a ®
X b), b ?
conditions become the
starting base for the
next message to produce
a ?b), b
G (a ®
X
a
Sylvain Hallé

62. Values inside messages
The decomposition rule for the existential quantifier creates
values inside messages
p
Å
p
Sylvain Hallé

63. Values inside messages
The decomposition rule for the existential quantifier creates
values inside messages
"There exists an x at
the end of path p such p
that j(x) is true"
Å
p
Sylvain Hallé

64. Values inside messages
The decomposition rule for the existential quantifier creates
values inside messages
"There exists an x at
the end of path p such p
that j(x) is true"
Å
p
"Add some value bi at
the end of path p"
Sylvain Hallé

65. Values inside messages
The decomposition rule for the existential quantifier creates
values inside messages
"There exists an x at
the end of path p such p
that j(x) is true"
Å
p
"Add some value bi at "Make sure that j
(x) is
the end of path p" true when x=bi"
Sylvain Hallé

66. Values inside messages
The decomposition rule for the existential quantifier creates
values inside messages
"There exists an x at
the end of path p such p
that j(x) is true"
Å
p
"Add some value bi at "Make sure that j
(x) is
the end of path p" true when x=bi"
...and repeat this for all possible values of bi
Sylvain Hallé

67. Values inside messages
The decomposition rule for the universal quantifier ranges over
values that are present in the message + potentially new values
p
Å
p
Sylvain Hallé

68. Values inside messages
The decomposition rule for the universal quantifier ranges over
values that are present in the message + potentially new values
"All values x at the
end of path p are such p
that j (x) is true"
Å
p
Sylvain Hallé

69. Values inside messages
The decomposition rule for the universal quantifier ranges over
values that are present in the message + potentially new values
"All values x at the
end of path p are such p
that j (x) is true"
Å
p
"Let Si = set of all values
already added at the end
of path p number of
+ any
other values"
Sylvain Hallé

70. Values inside messages
The decomposition rule for the universal quantifier ranges over
values that are present in the message + potentially new values
"All values x at the
end of path p are such p
that j (x) is true"
Å
p
"Let Si = set of all values "Make sure that j (x) is
already added at the end true for all values in Si"
of path p number of
+ any
other values"
Sylvain Hallé

71. Values inside messages
Conditions may add up and contradict themselves
Å
pÅ
Ø
p
Sylvain Hallé

72. Values inside messages
Conditions may add up and contradict themselves
"Value bi must be at
the end of path p"
Å
pÅ
Ø
p
Sylvain Hallé

73. Values inside messages
Conditions may add up and contradict themselves
"Value bi must be at "Value bi must not be at
the end of path p" the end of path p "
Å
pÅ
Ø
p
Sylvain Hallé

74. Values inside messages
Conditions may add up and contradict themselves
"Value bi must be at "Value bi must not be at
the end of path p" the end of path p "
Å
pÅ
Ø
p
"Stop exploring that
alternative"
Sylvain Hallé

75. Soundness and completeness
Problem
The rule for " values that were added by
checks all
previous applications of the rule for $
What if we add new values after?
Example: (" 0) Ù: y = 0)
p/x : x > ($
p/y
Consequence: soundness is guaranteed only if all $
are
processed before any "
(cf. Theorem 1 in the paper)
Sylvain Hallé

76. Implementation
Universal stub: web service that takes as input a declarative
specification of its behaviour
MESSAGES
move[ Structure of each
put[row,col], possible message
player];
DOMAINS
player: X,O,empty; Range of values
row,col: 1,2,3; for each element
SPECS
[move/board/A1 x] ((x) = ({empty})); LTL-FO+ formulas
...
The stub dynamically produces sequences of messages following
the specification
Sylvain Hallé

77. Implementation
Implemented in Java
·
· on a runtime monitor for LTL-FO+ "running in
Based
reverse"
SPEC
STUB
· stub dynamically produces sequences of messages
The
following the specification
Sylvain Hallé

78. Earlier solution*
A model checker can find a counter-example trace of a formula,
if there is one
.
Create a Kripke structure whose first n transitions are
unique (and correspond to the pre-existing trace)
.
Don't give any constraints for the (n+1)-th state
.
Run the model checker on that system with the
negated specification
.
The counter-example found gives us a possible
extension of the existing trace
* S. Hallé, WS-FM 2010
Sylvain Hallé

79. Showdown
We compared both approaches on the same input specification
Messages of the form
MESSAGES
m[p*]; } <m>
<p>0</p>
<p>2</p>
...
DOMAINS </m>
p : 1,2,...;
SPEC
G (" G ($: x=y))
m/p/x : X m/p/y
"Every value occurring in
some <p> must reappear
in all future messages"
Sylvain Hallé

80. Experiments
Exhibit A: we vary the size of the domain (i.e. the set of
possible values in message parameters)
MESSAGES
m[p*];
DOMAINS
p : 1,2,...,n;
SPEC
G (" G ($: x=y))
m/p/x : X m/p/y
Sylvain Hallé

81. Experiments
Exhibit A: we vary the size of the domain (i.e. the set of
possible values in message parameters)
1,000,000 With model checker
» 1.65 x
1300 ×
10,000
Time (ms)
100
1
0 2 4 6 8 10
Domain size
Sylvain Hallé

82. Experiments
Exhibit A: we vary the size of the domain (i.e. the set of
possible values in message parameters)
1,000,000 With model checker
» 1.65 x
1300 ×
10,000
Time (ms)
This paper's algorithm
» x
6.5 ×1.42
100
1
0 2 4 6 8 10
Domain size
Sylvain Hallé

83. Experiments
Exhibit A: we vary the size of the domain (i.e. the set of
possible values in message parameters)
1,000,000 With model checker
6:50 » 1.65 x
1300 ×
10,000
Time (ms)
This paper's algorithm
» x
6.5 ×1.42
100
0:00.375
1
0 2 4 6 8 10
Domain size
Sylvain Hallé

84. Experiments
Exhibit B: we vary the message arity (i.e. the maximum number
of parameters in messages)
MESSAGES
m[p{0,n}];
DOMAINS
p : 1,2,...;
SPEC
G (" G ($: x=y))
m/p/x : X m/p/y
Sylvain Hallé

85. Experiments
Exhibit B: we vary the message arity (i.e. the maximum number
of parameters in messages)
1,000,000 With model checker
» 1.64 x
8500 ×
10,000
Time (ms)
100
1
0 2 4 6 8 10
Message arity
Sylvain Hallé

86. Experiments
Exhibit B: we vary the message arity (i.e. the maximum number
of parameters in messages)
1,000,000 With model checker
» 1.64 x
8500 ×
10,000
Time (ms)
This paper's algorithm
= 375
100
1
0 2 4 6 8 10
Message arity
Sylvain Hallé

87. Experiments
Exhibit C: we measure processing time for each new message as
the trace lengthens
900
800
700
600
Time (ms)
500
400
300
200
100
0
0 2 4 6 8 10 12 14 16 18 20
Message #
Sylvain Hallé

88. Experiments
Exhibit C: we measure processing time for each new message as
the trace lengthens
900 With model checker
800 » 511
16x +
700
600
Time (ms)
500
400
300
200
100
0
0 2 4 6 8 10 12 14 16 18 20
Message #
Sylvain Hallé

89. Experiments
Exhibit C: we measure processing time for each new message as
the trace lengthens
900 With model checker
800 » 511
16x +
700
600
Time (ms)
500
400 This paper's algorithm
300 » 3.5
-0.2x +
200
100
0
0 2 4 6 8 10 12 14 16 18 20
Message #
Sylvain Hallé

90. Take-home points
1. Long-running web service transactions involve constraints
over message structure, values and sequence
.
2. Typical web service stubs only allow basic, pre-recorded
interactions
.
3. The logic LTL-FO+ can model these constraints
declaratively
.
4. Simulating a web service becomes a problem of
satisfiability solving over a set of LTL-FO+
formulas
.
5. An algorithm can generate realistic
sequences of messages
Sylvain Hallé