seerc - research centre of the university of sheffield and city college 1 leveraging semantic web...

SEERC - Research Centre of the University of Sheffield and CITY College 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 Centre2 Computer Science Department – CITY College

3 Department of Computer Science – University of Sheffield


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


Background and motivation


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


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


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


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


The starting point:semantic descriptions of Web

service behaviour


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


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)


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 WebProduction Rule Dialect has operational

semantics (specified as an LTS)RIF-PRD forthcoming W3C recommendation

• Why OWL?W3C recommendation


The destination:Stream X-machine model of Web service behaviour


Stream X-machines

• Stream X-Machines, specialisation of the X-machine model (Eilenberg 1974)8-tuple (Σ, Γ, Q, M, Φ, F, q0, m0) Extend Finite State Machines (FSM) with:

MemoryProcessing functions labelling transitions

Complete functional testing methodProven to reveal all faults in an implementation

given that certain design for test conditions are satisfied


Bank account service example

• Service operationsopendepositwithdrawgetBalanceclose

• Operations are invoked according to a protocol (choreography)


Bank account service SXM Model


SXM processing functions for operation withdraw

<function name="withdraw" input="withdraw" output="withdrawOut">

<precondition>withdraw.amount > 0 && balance > withdraw.amount</precondition>

<effect>balance = balance - withdraw.amount; withdrawOut.amount = withdraw.amount;</effect>

</function>

<function name="withdrawAll" input="withdraw" output="withdrawOut">

<precondition>withdraw.amount > 0 && balance == withdraw.amount</precondition>

<effect>balance = balance - withdraw.amount; withdrawOut.amount = withdraw.amount;</effect>

</function>


The derivation method:from IOPE descriptions

to an SXM model


Identifying state variables

(* wsdl:operation withdraw *)Forall ?account ?status ?balance ?request ?withdrawAmount (And ( ?account#Account

?account[hasStatus->?status]?account[hasBalance->?balance]?request#WithdrawRequest?request[hasAmount->?withdrawAmount] )

If And ( External (pred:string-equal(?status "ACTIVE")External (pred:numeric-greater-than-or-equal(?balance?withdrawAmount) )

Then Do( Retract (?account[hasBalance->?balance])Assert(?account[hasBalance->External(func:numeric-subtract(?balance ?withdrawAmount))])Retract (?request)(?response New(?response#WithdrawResponse))(?newBalance ?account[hasBalance->?newBalance])Assert (?response[hasAmount->?newBalance) ) )

• Two state variables: hasBalance hasStatus


Partition analysis

• The domains of state variables are determined by consulting their respective ranges in the OWL ontology.

<owl:DatatypeProperty rdf:about="#hasBalance"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> <rdfs:domain rdf:resource="#Account"/> <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/></owl:DatatypeProperty>

• hasBalance :== 0…∞• hasStatus :== {INITIAL, ACTIVE, CLOSED}


Partition analysis

• State :== hasStatus x hasBalance E.g. (INITIAL, 0), (INITIAL, 1), …, (ACTIVE, 0), (ACTIVE, 1), …

• Examine the preconditions to partition ranges of state variablesIf And ( External (pred:string-equal(?status "ACTIVE")

External (pred:numeric-greater-than-or-equal(?balance ?withdrawAmount) )

hasStatus: ?status = INITIAL ?status = ACTIVE

hasBalance: ?balance = 0 ?balance ≥ ?withdrawAmount AND ?withdrawAmount > 0

• Result hasStatus: {INITIAL}, {ACTIVE}, {CLOSED} hasBalance: {0}, {x | x>0}


Identifying preliminary states

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

• Six states


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 (hasStatus=ACTIVE and hasBalance>0) .


Merging states

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

distinguished


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.


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.


Determining memory updates for processing functions

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


Test case generation and execution


Generation of test cases

• SXM test generation based on Chow’s W-method for FSMs

• X = S(Φk+1 U Φk U … U Φ U {ϵ})W, where Φ 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


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

k=0 25 3.9 s

k=1 72 11.5 s

k=2 230 45.2 s


Execution of Test Cases


Summary and future work


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


Related work

• Sinha and Paradkar 2006OWL and SWRL rules to describe IOPESingle-state EFSMNo prescribed test generation method

• Keum et al. 2006Derive multi-state EFSM from plain WSDL +

user-supplied informationOnly derivation of states is described


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)


Thank you for your attention!

seerc - research centre of the university of sheffield and city college 1 leveraging semantic web...

Documents

seerc research centre

validation of web services

execution slide

conversational web services

test case execution

test case generation

motivation slide

execution of test cases