Model-Based Simulation of SOAP Web Services From Temporal Logic Specifications (Talk @ ICECCS 2011)

  • 1,226 views
Uploaded on

This paper presents a methodology for generating a web service "stub" that simulates the behaviour of a real-world SOAP web service. The simulation is driven by a formal description of the original …

This paper presents a methodology for generating a web service "stub" that simulates the behaviour of a real-world SOAP web service. The simulation is driven by a formal description of the original service's input and output parameters, messages, and ordering constraints between messages, using an extension of Linear Temporal Logic called LTL-FO+. This logic is rich enough to express complex behaviours taken from real-world web services, where the structure of future messages and valid parameter values are interdependent. Given a history of previous interactions, a sound, symbolic algorithm is described that generates on-the-fly a new message that is a valid continuation of that history with respect to the LTL-FO+ specification. By providing a faithful placeholder for an actual third-party web service, this algorithm can be used as a development and testing tool. Empirical evaluation shows how such an approach outperforms a previous attempt that relied on a model checker to produce each new message.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,226
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 CRSNGSylvain Hallé
  • 2. A motivating scenarioSylvain 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 clientSylvain Hallé
  • 9. A motivating scenarioSylvain 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 possibleSylvain 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 stubs responses are · under the developers controlSylvain 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 FlexibleSylvain 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 serviceSylvain 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 services 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 servicesSylvain Hallé
  • 32. Current solutions Problem . Responses are hard-coded messagesSylvain Hallé
  • 33. Current solutions <CartAdd> <CartID>ID123</CartID> <Items> <ItemID>123</ItemID> </Items> </CartAdd> Problem . Responses are hard-coded messagesSylvain Hallé
  • 34. Current solutions <CartAdd> <CartID>ID123</CartID> <Items> <ItemID>123</ItemID> </Items> </CartAdd> Problem . Responses are hard-coded messagesSylvain 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 messagesSylvain 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 languageSylvain Hallé
  • 41. Current solutionsstruct m_cart;if (m_cart.item add(m_item.id)else return XML("< Other way: program a realistic stub in a programming languageSylvain 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 formulaSylvain 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) . Dont 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 2010Sylvain Hallé
  • 45. New solution Dont 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 transactionSylvain 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 jSylvain 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 holdsSylvain 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 holdsSylvain 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 jholdsSylvain Hallé
  • 53. Decomposition rules Multiple branches = alternativesSylvain 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 ® XSylvain 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 holdSylvain 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 holdSylvain 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 holdSylvain 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 ® XSylvain 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 aSylvain 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 aSylvain Hallé
  • 62. Values inside messages The decomposition rule for the existential quantifier creates values inside messages p Å pSylvain 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" Å pSylvain 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 biSylvain 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 Å pSylvain 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" Å pSylvain 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Å Ø pSylvain Hallé
  • 72. Values inside messages Conditions may add up and contradict themselves "Value bi must be at the end of path p" Å pÅ Ø pSylvain 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Å Ø pSylvain 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 specificationSylvain 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 specificationSylvain 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) . Dont 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 2010Sylvain 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/ySylvain 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 sizeSylvain 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 papers algorithm » x 6.5 ×1.42 100 1 0 2 4 6 8 10 Domain sizeSylvain 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 papers algorithm » x 6.5 ×1.42 100 0:00.375 1 0 2 4 6 8 10 Domain sizeSylvain 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/ySylvain 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 aritySylvain 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 papers algorithm = 375 100 1 0 2 4 6 8 10 Message aritySylvain 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 papers 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 messagesSylvain Hallé