Survey On Service Composition Verification

1
Survey On Service Composition Verification
Testing

• By
• Venkateswara Prashanth Yerramilli
• Fakhrieh Shibani

2
Intended Goal

• Presenting the different Alternatives for
  Testing Service Oriented Applications
• and Survey Current Proposals For Doing it

3
Motivation

• Service Oriented Computing (SOC) is aimed at
  providing the bases for building software by
  assembling independent, loosely coupled services.
  As any software development activity, also
  building a composite service requires
• strategies for performing quality assessment of
  applications and, in particular, verification and
  testing

4
SOA

• Service-oriented architecture. Engineering a
  service-oriented computing system is a process of
  discovering and composing the proper services to
  satisfy a specification, whether it is expressed
  in terms of a goal graph (top), a workflow
  (bottom), or some other model

5
Web Service Composition Languages

• BPML- Business Process Modeling Language
• XLANG- Extension of Web Services Definition
  Language
• WSFL- Web Services Flow Language
• WS-BPEL- Web Services Business Process Execution
  Language
• WS-CDL- Web Services Choreography Description
  Language
• WSCI- Web Services Choreography Interface
• Now we are going to discuss Verification,
  Validation,
• Testing of Service and Service Composition.

6
Services can be composed using

• Orchestration Executable Process
• It Relates to the execution of specific
  business processes. WS BPEL is one of the
  language which executes on an orchestration
  engine.
• ChoreographyMulti-party Collaboration
• Describes externally observable interactions
  between web services
• It is somewhat like WSDL and can describe multi
  party contracts.

7
Orchestration View

• It Exposes the Internal logic of a single
  component by specifying the control flow and data
  flow dependencies of that component.
• Orchestrator gives the order in which the
  composite services are invoked.
• Flow of such interactions can be specified in
  either
• A) Structured way using operators of sequence,
  iteration
• branching
• B) Unstructured way specifying pair wise
  dependencies among basic activities.( i.e. by
  writing links)

8
Choreography View

• It exposes the flow of interaction among all
  involved parties.
• It allows for the definition of protocols that
  the parties have to follow.
• Two main approaches for choreography are
• Global Model Protocol described from global
  perspective the messages exchanged by parties.
• Interaction Model Services describe temporal and
  logical dependencies among messages it exchanges.

9
Orchestration vs. Choreography
So It is important to distinguish between
Orchestration-based Choreography-based Testing
In Orchestration, One web service flows to one or
more other web services. In choreography, web
services collaborate back and forth.
10
Testing Orchestrations

• Two Well Known Levels of Testing
• Unit Testing
• Integration Testing
• (Most Importantly no information about behavior
  of partners is available)

11
Unit Testing

• Two Main Approaches for testing units
• Specification based or Black Box Test cases are
  generated from specification without
  consideration about implementation.
• Implementation based or White Box Test cases are
  generated from implementation or actual code.

12
Functional Orchestrations

• Functional Black Box Testing When the
  orchestrator is implemented in a language that is
  different from the specification.
• Functional White Box Testing When the
  description of the orchestrator coincides with
  its implementation.

13
Test Case Generation

• Can be found by applying principles of white box
  testing mainly test generation from control and
  data flow abstractions
• Orchestration computation structure can be
  represented by flow graph which should manage the
  following features.
• Concurrency They should model parallelism.
• Links or synchronization Several parallel paths
  of executions can be synchronized by links.
• Exceptions and transactional scopes They should
  model flows of executions that are activated
  when some activity fails.
• Events and Timers They should accommodate
  executions that are activated at certain time.

14
Test Oracle

• It is a mechanism for determining the behavioral
  correctness of executions.
• For Black Box Testing Oracles would be generated
  directly from orchestration definition
• Hence expected result is given by observed
  outputs
• For White Box Testing Oracles should be
  generated from a different specification of the
  behavior of the component.
• Also in service realm they would be generated
  from the definitions of choreographies the
  orchestrator is in.

15
Test Execution

• Orchestration Testing here resembles ordinary
  Testing
• Test Execution requires construction of drivers,
  stubs, mock objects, and simulating the behavior
  of other parts of the system.
• Monitoring the Execution I.e unit under test
  should be run with corresponding inputs and
  observable effects should be collected.
• Once Test case is run, then we can decide whether
  the unit behaves as expected or not.

16
Integration Testing

• Aimed at exercising interaction among several
• components and not just single units
• Hence it involves execution of several
  components.
• A plan for integration testing involves
  strategies like top down, bottom up, threads, big
  bang, critical modules.

17
Integration Testing (contd)

• Takes advantage of the description of the
• interactions among partners for selecting test
  cases.

18
Testing Choreographies

• They capture the interactions among services.
• Unit Testing
• A unit is a particular partner of choreography,
  and unit testing is aimed at finding whether a
  particular partner follows an interaction model
  or not which is also called as conformance
  testing, which is kind of like black box testing,
  because test cases are generated from the
  specification without any knowledge about the
  implementation.

19
Test case Generation

• Global and Local styles of choreography
• Global describes the interaction among all agents
• Local describes the order in which messages are
  received and sent by a particular component.

20
Integration Testing - Choreography

• Integration among partners for selecting test
  cases
• Test Case Generation
• We reuse techniques that take advantage of
  interaction model for selecting test cases with
  nice interactions
• They start from behavioral specification of
  services and a test directive and produce as an
  output a set of test cases.
• The final observed test cases are paths of the
  state machines which cover the given directive

21
Testing BPEL-base WSC using HPNs

• Relationships between BPEL-based WSC and HPNs are
  constructed ( Translation from BPEL to HPNs)
• Generated HPN can be verified using testing
  coverage and reduction techniques developed for
  HPNs

22
What are Petri Nets?

• Modeling and specification Language for
  information System behavior
• Advantages
• Ability to model concurrency of the systems
• Analyze concurrent behavior
• Express Dynamically changed software

23
Translation Process

• Translating an operation consists of input and
  output messages into a HPN ( Atomic operation
  level)

Atomic Operation HPN
24
Translation Process (Contd)

• Generating HPNs denoting relationships on
  operations such as one input message of one
  operation is the output message of another
  (Operation Cluster translation)

Basic activity HPN
25
Translation Process (Contd)

• Combining HPNs produced by the previous steps
  into one HPN according to activity relationships
  defined in BPEL specification

Structured Activity HPN
26
Testing

• The HPN generated will be checked including the
  operation checking , operation cluster checking
  and service cluster checking
• This testing is performed by extracting a set of
  paths that cover all the arcs of the graph using
  generation method, coverage and reduction
  techniques of HPN.

27
Tool for Formal Verification of WSC based on
Extended p-Calculus

• Features
• The tool is composed of three types of formal
  verification techniques
• Open Bisimulation Checking
• Property Checking based on µ-Calculus
• Compatibility Checking based on p-Calculus

This Combination allows for the checking of the
control flow of the orchestration properties
More complete validity checking about the
orchestration
28
Tool Features (Contd)

• Automatic mapping between BPEL4WS and p-Calculus
• Service compatibility examination is introduced
  into web service discovering and matching method

Automation of checking, ease of operation by
user, and automatic marking of error pathways for
the orchestration
29
Open Bisimulation

• Open Bisimulation is a new formulation of
  bisimulation.
• Bisimulation is an equivalence relation between
  state transition systems. (Wikipedia
• So, The open bisimulation can check whether
  service composition satisfies the customers
  demands and the designer specification

30
Model Checking based on µ-Calculus

• The µ-calculus (also modal µ calculus) is a class
  of temporal logics. It is used to describe
  properties of labeled transition systems and for
  verifying their properties (Wikipedia)
• So, The model checking based on µ-Calculus checks
  whether the orchestration satisfies the
  liveliness, safety, faireness and reach ability

31
Compatibility Checking based on p-Calculus

• p-calculus is an approach to formally describe
  concurrent systems whose configuration may change
  during the computation. (Wikipedia)
• So, Checking compatibility checks the
  compatibility of composite system, which
  eliminates the bad behaviors from the
  orchestration ( types mismatch, improper
  replacement of service and deadlock

32
Conclusion

• Dynamism and concurrency are essential features
  of web Service Composition that should be handled
  and considered in Testing, verification and
  validation Techniques

33

• Thank You