Model-Based Simulation of SOAP Web Services From Temporal Logic Specifications (Talk @ ICECCS 2011)
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,478 views

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.

Statistics

Views

Total Views
1,478
Views on SlideShare
1,423
Embed Views
55

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 55

http://www.leduotang.com 55

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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é
  • A motivating scenarioSylvain Hallé
  • A motivating scenario $Sylvain Hallé
  • A motivating scenario ?Sylvain Hallé
  • A motivating scenario ?Sylvain Hallé
  • A motivating scenario !Sylvain Hallé
  • A motivating scenario ? !Sylvain Hallé
  • A motivating scenario Interaction ? ! Web service Web clientSylvain Hallé
  • A motivating scenarioSylvain Hallé
  • 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é
  • 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é
  • 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é
  • A SOAP web service Requests and responses form a transaction...Sylvain Hallé
  • A SOAP web service Requests and <ItemSearch> <Term>abc</Term> responses form a </ItemSearch> transaction...Sylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • A SOAP web serviceSylvain Hallé
  • A SOAP web service <CartCreate> </CartCreate>Sylvain Hallé
  • A SOAP web service <CartCreate> </CartCreate> <CartCreateResponse> <CartID>ID123</CartID> </CartCreateResponse>Sylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • Current solutions : create mock web servicesSylvain Hallé
  • Current solutions Problem . Responses are hard-coded messagesSylvain Hallé
  • Current solutions <CartAdd> <CartID>ID123</CartID> <Items> <ItemID>123</ItemID> </Items> </CartAdd> Problem . Responses are hard-coded messagesSylvain Hallé
  • Current solutions <CartAdd> <CartID>ID123</CartID> <Items> <ItemID>123</ItemID> </Items> </CartAdd> Problem . Responses are hard-coded messagesSylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • Current solutions Other way: program a realistic stub in a programming languageSylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • Decomposition rules Decomposition rules for some operators:Sylvain Hallé
  • Decomposition rules Decomposition rules for some operators: "j must hold in every message"Sylvain Hallé
  • Decomposition rules Decomposition rules for some operators: "j must hold in every message" Create a message that fulfills jSylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • Decomposition rules Multiple branches = alternativesSylvain Hallé
  • Decomposition rules Multiple branches = alternatives "j must hold eventually" In the current message... In a future message...Sylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • Values inside messages The decomposition rule for the existential quantifier creates values inside messages p Å pSylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • Values inside messages Conditions may add up and contradict themselves Å pÅ Ø pSylvain Hallé
  • Values inside messages Conditions may add up and contradict themselves "Value bi must be at the end of path p" Å pÅ Ø pSylvain Hallé
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é
  • 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é