Upload
sylvain-halle
View
537
Download
0
Embed Size (px)
DESCRIPTION
Given a web service W, a stub is a simple service S intended to impersonate W and simulate some of its input-output patterns. When W's behavior is represented by a logic formula φ, S can use a satisfiability solver to drive the simulation and generate valid messages compliant with φ. A satisfiability solver for a variant of first-order temporal logic, called LTL-FO+, is described. Using a chain of existing, off-the-shelf tools, a stub can be generated from a set of LTL-FO+ formulæ expressing a wide range of constraints, including message sequences, parameter values, and interdependencies between both. This, in turn, produces a faithful simulation of the original service that can be used for development and testing.
Citation preview
Sylvain Hallé
Sylvain Hallé
Automated Generation of Web ServiceStubs Using LTL Satisfiability Solving
Université du Québec à ChicoutimiQuébec, CANADA
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
?
Sylvain Hallé
A motivating scenario
!
Sylvain Hallé
A motivating scenario
!
?
Sylvain Hallé
A motivating scenario
Sylvain Hallé
We want to do, ...as automatically as possible
...impersonate the client, send test sequences to the service
! Check if service does what we expect/understand
...impersonate the service, generate responses to the client
! Environment closedmodel checking possibleÞ
DRIVER STUB
� �
A motivating scenario
Sylvain Hallé
Some reasons for creating a stub:
- Test a client under development, withoutperforming real actions on the actualservice
- Provide a closed environment for model checking
- Alternative to sandboxes: the stub's responsesare under the developer's control
STUB
A motivating scenario
Sylvain Hallé
Current solutions
soapUI: create mock web services
Sylvain Hallé
Current solutions
Problem:
- Most solutions consider request-response patterns asindependent of each other
- Once a "mock" response is sent for a request, thestub forgets everything about the transaction history
- We know this is not always the case: multi-messagedependencies
Sylvain Hallé
Web service messaging
At the message level, the interaction between two services can be done in two ways:
SOAP interface
- HTTP POST requests- Arbitrary XML structures- Carried through payload
<Message> <Action> </Action> <Items> <Item> </Item> <Item> < </Items></Message>
CreateCart
123456 /Item>
Sylvain Hallé
At the message level, the interaction between two services can be done in two ways:
REST interface
- HTTP GET requests- Attriute-value pairs- Carried through URL
http://service.com/createCart? item=123&item=456
Web service messaging
Sylvain Hallé
Web service messaging
This work concentrates on REST services
! Simpler, but frequent- 85% of Amazon's WS API is accessed through its
REST interface
! Improper use of the term!
Sylvain Hallé
Formalization
Let...
A: set of action namesP: set of parameter namesD: set of value names
An HTTP GET request r = (a, ) is an element ofDA P 2 )
Example:
remove?id=123&item=34&item=56 is the pair(remove,
«
´ ( ®
« « «), where (id) = {123} and (item) = {34, 56}
Sylvain Hallé
An example
Simple REST web service tha manages a stock portfolio
search?term=abcdstock?item=34new-cartadd?id=123&item=34remove?id=123&item=34empty?id=123commit?item=34req-paymentlogout
stocks?stock=1234&stock=5678...stock-info?price=5&name=abccart-info?id=123&empty=truecart-info?id=123&empty=Xcart-info?id=123&empty=Xcart-info?id=123&empty=trueconfirmed&item=34&item=...payment-formbye
Requests Responses
Sylvain Hallé
Dependencies
search?term=abcd
stock?item=1234
new-cart
commit?item=1234
add?id=1&item=1234
commit?item=5678
logout
stocks?stock=1234&stock=5678
stock-info?item-id=1234&price=5
cart-info?id=1&empty=true
confirmed?item=1234
cart-info?id=1&empty=false
confirmed?item=1234&item=5678
payment-form
Sylvain Hallé
Dependencies
1. No element can be added to the portfolio before some stock information has been asked
search?term=abcd
stock?item=1234
new-cart
commit?item=1234
add?id=1&item=1234
commit?item=5678
logout
stocks?stock=1234&stock=5678
stock-info?item-id=1234&price=5
cart-info?id=1&empty=true
confirmed?item=1234
cart-info?id=1&empty=false
confirmed?item=1234&item=5678
payment-form
Sylvain Hallé
Dependencies
2. If a user commits to buy at least one item, a logout request must be replied with payment form instead of bye
search?term=abcd
stock?item=1234
new-cart
commit?item=1234
add?id=1&item=1234
commit?item=5678
logout
stocks?stock=1234&stock=5678
stock-info?item-id=1234&price=5
cart-info?id=1&empty=true
confirmed?item=1234
cart-info?id=1&empty=false
confirmed?item=1234&item=5678
payment-form
Sylvain Hallé
Dependencies
search?term=abcd
stock?item=1234
new-cart
commit?item=1234
add?id=1&item=1234
commit?item=5678
logout
stocks?stock=1234&stock=5678
stock-info?item-id=1234&price=5
cart-info?id=1&empty=true
confirmed?item=1234
confirmed?item=1234&item=5678
payment-form
cart-info?id=1&empty=false
3. Once a cart is created, the same cart ID must be passed in all cart requests
Sylvain Hallé
Dependencies
search?term=abcd
stock?item=1234
new-cart
commit?item=1234
add?id=1&item=1234
commit?item=5678
logout
stocks?stock=1234&stock=5678
stock-info?item-id=1234&price=5
cart-info?id=1&empty=true
confirmed?item=1234
cart-info?id=1&empty=false
confirmed?item=1234&item=5678
payment-form
4. Any stock ID sent in a commit request must appear in all future confirmed messages
Sylvain Hallé
The service's behavior follows constraints on...
1. of operations only2. Parameter only3. at the same time
: extension of LTL with quantifiers on message parameters (Hallé & Villemaire, EDOC 2008)
Sequencesvalues
Both
LTL-FO+
Challenge
Sylvain Hallé
For example, constraint 4:
Any stock ID sent in a commit request must appear in allfuture confirmed messages
Detailed semantics in the paper!
Using LTL-FO+ as the specification language, producing a web service stub becomes an application of LTL-FO+ satisfiability solving
Challenge
G (commit i : G (confirmed j : i=j))® " ® $id id
Sylvain Hallé
Problem
Given...
- A pre-existing trace of requests- An LTL-FO+ formula
Produce:
- An extension of the trace (by one message) thatsatisfies the formula
Sylvain Hallé
An "old" trick
A model checker can find a counter-example trace of a formula, if there is one
Create a Kripke structure whose first n transitions areunique (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 thenegated specification
The counter-example found gives us a possibleextension of the existing trace
Sylvain Hallé
The Kripke structure
We fix the arity of GET requests to some integer k. Any request is encoded into a state with 2k+2 variables:
- A variable a with domain A- k variables p1 to pk, with domain P or # (undefined)- k variables v1 to vk, with domain D or # (undefined)- A counter variable c
Sylvain Hallé
The Kripke structure
The transition relation defines a set of rules:
1. The counter increments by 12. The m-th state encodes the m-th message of the trace
(fixes the values of all parameters)3. An empty p entails an empty v4. All empty ps are at the end5. For a given action, all and only the parameters defined
in the action's schema are present6. For a given parameters, the corresponding value belongs
to the parameter's domain
Sylvain Hallé
The web service stub
Small PHP script (20 kb) that:
- Records the trace (to a file)- When invoked, produces a
NuSMV input file
- Executes NuSMV in thebackground
- Interprets the result andgenerates the desired response message
- Also makes sure that agiven message contains all theright parameters andacceptable values
REQUESTS new-cart[]; add[id,item]; ...
DOMAINS id: 0,1; item: item1, item2; ...
SPECS G (add -> cart-info); G (<id:i> G [id:j] i=j); ...
Sylvain Hallé
Experimental results
On the stock portfolio example...
- Between round-trip for arequest/response
- Grows with trace length and data domain size (see graphsin paper)
- Reasonable for testing purposes
- Step forward compared to hard-coded stock responses
0.4 and 1.6 seconds
Sylvain Hallé
Open issues and comments
1. Messages are flat.What about SOAP requests?
2. Quantifiers are eliminated explicitly.Best translation?
3. Use of a model checker.Dedicated algorithm better?
4. No incremental support.Recycle computation of n-th step to performn+1-th step?
Sylvain Hallé
Open issues and comments
5. Declarative programming of a web service.
We almost programmed a web service, using fourshort LTL-FO+ formulas...