automated generation of web service stubs using ltl satisfiability solving (ws-fm 2010)

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é


$

Sylvain Hallé


?

Sylvain Hallé


!

Sylvain Hallé


!

?

Sylvain Hallé


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

� �


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


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


Sylvain Hallé


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




confirmed?item=1234



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




confirmed?item=1234



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




confirmed?item=1234


payment-form


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




confirmed?item=1234



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...

automated generation of web service stubs using ltl satisfiability solving (ws-fm 2010)

Documents