Leveraging Semantic Web Service Descriptions for Validation by Automated Functional Testing

1
Leveraging Semantic Web Service Descriptions for
Validation by Automated Functional Testing

• Ervin Ramollari1, Dimitrios Kourtesis1,
• Dimitris Dranidis2, and Anthony Simons3
• 1 SEERC South East European Research Centre
• 2 Computer Science Department CITY College
• 3 Department of Computer Science University of
  Sheffield

2
Presentation outline

1. Background and motivation
2. The starting point semantic descriptions of Web
   service behaviour
3. The destination Stream X-Machine model of Web
   service behaviour
4. The derivation method from IOPE descriptions to
   an SXM model
5. Test case generation and execution
6. Summary and future work

3
Background and motivation
4
Testing and validation of Web services

• A service-oriented environment can be open
• Integration of third-party Web services
• Dependability is a major challenge
• Service validation is crucial for engineering
  dependable service-based systems
• Web service implementation should conform to
  given functional/behavioural specifications
• Validation done through functional testing
• Manual Web service testing is highly laborious
• Definition of test cases, execution and evaluation

5
Leveraging SWS descriptions for automating
testing

• Semantic Web Service descriptions are utilised
  for automating a range of activities
• Service discovery, composition, mediation
• Less attention has been paid to using them for
  service testing and validation
• Information in SWS descriptions could be
  exploited for automating test case generation and
  execution
• This information should be represented in a
  formalism amenable to processing by existing
  algorithms and tools for test case generation and
  execution

6
Our background work

• Functional testing of Web services
• Automated generation and execution of test cases
  (with completeness guarantees)
• Stream X-Machine (SXM) formalism
• Used for modelling the behaviour of stateful and
  conversational Web services
• Associated with proven testing method revealing
  all inconsistencies between implementation and
  model
• Tool support
• SXM modelling, model animation, test case
  generation, test case execution on WS

7
Aim of this work

• Could we derive a SXM model from a Semantic Web
  Service description for the purposes of automated
  testing and validation?
• The derivation approach should be
• Automatable to the greatest extent possible
• Independent of any particular SWS framework
• Using Semantic Web technology standards

8
The starting pointsemantic descriptions of Web
service behaviour
9
Semantic descriptions of Web service behaviour

• SWS frameworks like OWL-S, WSMO (and ad-hoc
  SA-WSDL combinations) are heterogeneous
• A commonality is describing service operations in
  terms of inputs, outputs, preconditions, and
  effects (IOPE)
• Transformation of inputs to outputs
• Conditional effects on the internal state
• All SWS frameworks support IOPE in some form
• OWL-S Inputs, Outputs, Preconditions, Results
• WSMO Preconditions, Postconditions, Assumptions,
  Effects
• SAWSDL ModelReference annotations on operations

10
IOPE-based descriptions

• IOPE is useful for describing stateful and
  conversational Web services
• E.g. shopping cart, e-banking, order management
• IOPE representation requires a combination of
• Production rules for expressing
• Conditions for execution (preconditions)
• Actions of execution (effects in terms of
  assertions and retractions)
• Ontology for expressing
• Structure of inputs and outputs
• Internal state-related variables (i.e. not
  visible in WSDL)

11
IOPE-based descriptions with RIF-PRD OWL

• In this paper we adopt RIF-PRD and OWL as a
  possible combination
• Why RIF-PRD?
• RIF as rule language for the Semantic Web
• Production Rule Dialect has operational semantics
  (specified as an LTS)
• RIF-PRD forthcoming W3C recommendation
• Why OWL?
• W3C recommendation

12
The destinationStream X-machine model of Web
service behaviour
13
Stream X-machines

• Stream X-Machines, specialisation of the
  X-machine model (Eilenberg 1974)
• 8-tuple (S, G, Q, M, F, F, q0, m0)
• Extend Finite State Machines (FSM) with
• Memory
• Processing functions labelling transitions
• Complete functional testing method
• Proven to reveal all faults in an implementation
  given that certain design for test conditions are
  satisfied

14
Bank account service example

• Service operations
• open
• deposit
• withdraw
• getBalance
• close
• Operations are invoked according to a protocol
  (choreography)

15
Bank account service SXM Model
16
SXM processing functions for operation withdraw

• ltfunction name"withdraw" input"withdraw"
  output"withdrawOut"gt
•   ltpreconditiongtwithdraw.amount gt 0 balance gt
  withdraw.amountlt/preconditiongt
•   lteffectgtbalance balance - withdraw.amount
  withdrawOut.amount withdraw.amountlt/effectgt
•   lt/functiongt
• ltfunction name"withdrawAll" input"withdraw"
  output"withdrawOut"gt
•   ltpreconditiongtwithdraw.amount gt 0 balance
  withdraw.amountlt/preconditiongt
•   lteffectgtbalance balance - withdraw.amount
  withdrawOut.amount withdraw.amountlt/effectgt
•   lt/functiongt

17
The derivation methodfrom IOPE descriptions to
an SXM model
18
Identifying state variables

• ( wsdloperation withdraw )
• Forall ?account ?status ?balance ?request
  ?withdrawAmount (
• And ( ?accountAccount
• ?accounthasStatus-gt?status
• ?accounthasBalance-gt?balance
• ?requestWithdrawRequest
• ?requesthasAmount-gt?withdrawAmount )
• If And ( External (predstring-equal(?status
  "ACTIVE")
• External (prednumeric-greater-than-or-equal(?b
  alance
• ?withdrawAmount) )
• Then Do( Retract (?accounthasBalance-gt?balance)
• Assert(?accounthasBalance-gtExternal(funcnumer
  ic- subtract(?balance ?withdrawAmount)))
• Retract (?request)
• (?response New(?responseWithdrawResponse))
• (?newBalance ?accounthasBalance-gt?newBalance)
  
• Assert (?responsehasAmount-gt?newBalance) ) )
• Two state variables
• hasBalance

19
Partition analysis

• The domains of state variables are determined by
  consulting their respective ranges in the OWL
  ontology.
• ltowlDatatypeProperty rdfabout"hasBalance"gt
• ltrdftype rdfresource"owlFunctionalProperty
  "/gt
• ltrdfsdomain rdfresource"Account"/gt
• ltrdfsrange rdfresource"xsdnonNegativeInteg
  er"/gt
• lt/owlDatatypePropertygt
• hasBalance 08
• hasStatus INITIAL, ACTIVE, CLOSED

20
Partition analysis

• State hasStatus x hasBalance
• E.g. (INITIAL, 0), (INITIAL, 1), , (ACTIVE, 0),
  (ACTIVE, 1),
• Examine the preconditions to partition ranges of
  state variables
• If And ( External (predstring-equal(?status
  "ACTIVE")
• External (prednumeric-greater-than-or-
  equal(?balance ?withdrawAmount) )
• hasStatus
• ?status INITIAL
• ?status ACTIVE
• hasBalance
• ?balance 0
• ?balance ?withdrawAmount AND ?withdrawAmount gt
  0
• Result
• hasStatus INITIAL, ACTIVE, CLOSED
• hasBalance 0, x xgt0

21
Identifying preliminary states

• The preliminary state space is defined as the
  product of the state variable partitions.
• Six states

22
Determining transition pre-states

• An input is accepted at a state (pre-state) iff
  the preconditions are satisfied at the pre-state
• E.g. the preconditions of the withdraw operation
  triggered WithdrawRequest are (hasStatusACTIVE
  and hasBalancegt0) .

23
Merging states

• Preliminary states in which the same set of
  inputs is accepted are merged
• Cannot be distinguished

24
Determining transition post-states

• Apply the effects of the invoked operation on the
  pre-state to determine the possible post-states.
• WithdrawRequest leads to two possible post-states
• Two different transitions labelled by different
  processing functions
• Isolated states are removed.

25
Determining guard conditions for processing
functions

• The guard conditions are the same as the
  corresponding rule preconditions
• Any predicates already satisfied in the pre-state
  are omitted.

26
Determining memory updates for processing
functions

• The memory updates of each processing function
  consist only of the effects which update the
  memory (M) variables.

27
Test case generation and execution
28
Generation of test cases

• SXM test generation based on Chows W-method for
  FSMs
• X S(Fk1 U Fk U U F U ?)W, where
• F is the set of processing functions (type of the
  machine)
• W is the characterisation set
• S is the state cover
• k is an estimate of maximum path length between
  redundant states in the implementation
• Supported by tools

29
From abstract to concrete test cases

• The generated test cases are at the same level of
  abstraction as the specification and cannot be
  executed directly
• Abstract test cases are transformed to JUnit test
  cases
• Generation of Java clients with libraries such as
  WSDL2Java

Value of k No. of test sequences Execution time
k0 25 3.9 s
k1 72 11.5 s
k2 230 45.2 s
30
Execution of Test Cases
31
Summary and future work
32
Summary of the approach

• Leveraging SWS descriptions for the added-value
  of testing and validation of services
• Strengths of the approach
• SWS framework-independent
• Testing supported by existing tools
• Uses proven SXM functional testing method

33
Related work

• Sinha and Paradkar 2006
• OWL and SWRL rules to describe IOPE
• Single-state EFSM
• No prescribed test generation method
• Keum et al. 2006
• Derive multi-state EFSM from plain WSDL
  user-supplied information
• Only derivation of states is described

34
Future work

• Investigate the decidability of the algorithm and
  the automation of all steps
• Implement tools supporting the transformation
• Prove equivalence relationship among original
  specification and derived SXM model
• Utilise SWS grounding information to automate the
  transformation of abstract test cases to concrete
  (SA-WSDL annotations pointing to RIF-PRD and OWL)

35
Thank you for your attention!