Deriving composite service specifications

www.s-cube-network.eu

Deriving Composite Service Specifications

S-Cube Industry Workshop @ Thales

George Baryannis, Manuel Carro and Dimitris Plexousakis

University of Crete (UoC) Universidad Politécnica de Madrid (UPM)

George Baryannis – S-Cube Industry Workshop @ Thales – 24/2/2012 © S-Cube – 2/18

The Need for (Composite) Service Specifications Service specifications can be employed for

– Constructing a service based on a set of requirements

– Checking conformance of an existing service to a set of requirements

– Auditing processes that check third party or legacy code conformance

– Verification techniques

– Evaluating results of service adaptation/evolution

– Detecting inconsistencies in a composite service

http://www.s-cube-network.eu/km/terms/s/service-specification/

http://www.s-cube-network.eu/km/terms/v/verification/

http://www.s-cube-network.eu/km/terms/a/adaptation/

http://www.s-cube-network.eu/km/terms/e/evolution/

http://www.s-cube-network.eu/km/terms/s/service-composition/

The Special Case of Services Existing service description and composition frameworks don’t

address the problem of automatically producing specifications for a composite service

– At best, they support some kind of description of atomic services, as well as a description of the composition schema

The case of services introduces special characteristics – We cannot rely on the implementation, as is common in e.g.

programming specifications

– Any service is only known through its specification

– A composite service is characterized by its composition schema

© S-Cube – 3/18 George Baryannis – S-Cube Industry Workshop @ Thales – 24/2/2012

http://www.s-cube-network.eu/km/terms/c/composition-schema/

Specification Semantics


Proposed Method Our approach involves characterizing the meaning of all

fundamental control constructs used in a composition – by means of the preconditions and postconditions of the composed

services

Using this characterization we propose a derivation process based on structural induction

– The composite specification is constructed using a bottoms-up approach

– Produces specifications syntactically similar to those of the constituent services, to facilitate recursive reasoning

– Relies on the availability of the composition schema (e.g. from the BPEL document of the composite service)

– Applicable to any block-structured process, or graph-based ones that can be transformed to block-structured equivalents


Calculating Pre- And Post-Conditions Sequence

a, b and c denote the states before the execution of A, after A and before B and after the execution of B.

z contains all input variables for B, including any ones that are not produced as an output of A (they are routed through A)

Based on the individual specifications, we deduce the following:


Calculating Pre- And Post-Conditions AND-Split/AND-Join

The diverging branches execute concurrently and both activities need to complete

The derived specification is:


Calculating Pre- And Post-Conditions OR-Split/OR-Join

Not all of the branches are necessarily activated and there is no need for synchronization at the merging stage



Calculating Pre- And Post-Conditions XOR-Split/XOR-Join

Only one of the diverging branches is to be executed each time and is the only one to provide results



Calculating Pre- And Post-Conditions Conditional Constructs

The truth value of condition C determines which of A and B is going to be executed.



Example

Using the specifications calculated previously, we gradually derive the following specification for this example composite process (xs and ys denote the input and output at state s):

∀𝑥0 ∃𝑦1 ∙

𝑃𝐴 𝑥0, 0 ⇒ 𝑄𝐴 𝑦1, 1


http://www.s-cube-network.eu/km/terms/p/process/

Example

The sequential composition of A and the parallel execution of B and C is specified by:

∀𝑥0, 𝑥1, 𝑥2 ∃𝑦1,𝑦2 ∙

𝑃𝐴 𝑥0, 0 ∧ 𝑷𝑩 𝒙𝟏,𝟏 ∧ 𝑷𝑪 𝒙𝟏,𝟏 ⇒ 𝑄𝐴 𝑦1, 1 ∧ 𝑸𝑩 𝒚𝟐,𝟐 ∧ 𝑸𝑪 𝒚𝟐,𝟐


Example

Adding service D to the sequence results in the following specification:

∀𝑥0, 𝑥1, 𝑥2, 𝑥3 ∃𝑦1,𝑦2,𝑦3 ∙

𝑃𝐴 𝑥0, 0 ∧ 𝑃𝐵 𝑥1, 1 ∧ 𝑃𝐶 𝑥1, 1 ∧ 𝑷𝑫 𝒙𝟐,𝟐 ⇒ 𝑄𝐴 𝑦1, 1 ∧ 𝑄𝐵 𝑦2, 2 ∧ 𝑄𝐶 𝑦2, 2 ∧ 𝑸𝑫 𝒚𝟑,𝟑


Example

The composite specification is completed by adding the specification for the conditional execution of F and E:

∀𝑥0, 𝑥1, 𝑥2, 𝑥3, 𝑥4, 𝑥5∃𝑦1,𝑦2,𝑦3,𝑦6 ∙

𝑃𝐴 𝑥0, 0 ∧ 𝑃𝐵 𝑥1, 1 ∧ 𝑃𝐶 𝑥1, 1 ∧ 𝑃𝐷 𝑥2, 2 ∧ 𝑪𝑪𝑪𝑪 𝒙𝟑,𝟑 ∧ 𝑷𝑬 𝒙𝟒,𝟒 ∨ ¬𝑪𝑪𝑪𝑪 𝒙𝟑,𝟑 ∧ 𝑷𝑭 𝒙𝟓,𝟓 ⇒

𝑄𝐴 𝑦1, 1 ∧ 𝑄𝐵 𝑦2, 2 ∧ 𝑄𝐶 𝑦2, 2 ∧ 𝑄𝐷 𝑦3, 3 ∧𝑪𝑪𝑪𝑪 𝒙𝟑,𝟑 ∧ 𝑸𝑬 𝒚𝟔,𝟔 ∨ ¬𝑪𝑪𝑪𝑪 𝒙𝟑,𝟑 ∧ 𝑸𝑭 𝒚𝟔,𝟔


The Case of Loops (1) Loops pose a significant challenge: there is no a priori

knowledge of the number of iterations

At best, we may have an upper limit, that can lead to a recursive specification

– Expressive and concise, but difficult to work with using theorem provers

Without an upper limit, we can characterize a loop through its invariant

– A statement that is true both before and after each iteration of the loop

– By definition, the loop invariant is a loop precondition (𝐼 ⇒ 𝑃)

– If C is the condition of the loop, then its postcondition Q is derived through the implication (𝐼 ∧ ¬𝐶 ⇒ 𝑄)


The Case of Loops (2) Generating loop invariants is once again affected by the

special characteristics of services – Any generated invariant can only be an approximation of the

invariant that would be produced based on the actual loop code

– Stronger approximations are required to derive a useful precondition (one that disallows invalid executions)

– Weaker approximations are required to derive a useful postcondition (one that doesn’t leave out any execution results)

– Existing loop invariant generation methods can be employed (provided they are static, i.e. they don’t depend on information gathered by executing the service) but need to be adapted to take into account the above points.


The Case of Asynchronous Execution

The client invokes a service, but does not wait for the response

– Precondition evaluation is not affected

– Postconditions must be expressed and evaluated in the same context as the corresponding preconditions

To deal with asynchronous execution, we employ the Static Single Assignment (SSA) form

– There is exactly one assignment for each distinct variable name

– For any further assignment, variable renaming is employed, so that a history of all previous values is kept

- e.g. if we want to modify the value of variable y, a new variable, y1, is created to represent the new value.


Conclusions & Future Work

This work offers a method to derive composite specifications given a composition schema and the specifications of the participating service

– The derivation is based on structural induction and a set of rules defined for fundamental control constructs

– Guidelines to handle the cases of loops and asynchronous execution are also provided

An implementation of the proposed approach is currently underway

Further issues involve applying simplification techniques to the derived specifications, as well as examining issues related to the frame problem in combination with the derivation process


Investor Relations

Deriving composite service specifications