deriving specifications for composite web services

George Baryannis1, Manuel Carro2 and Dimitris Plexousakis1

[email protected] [email protected] [email protected]

1Department of Computer Science, University of Crete, and Institute of Computer Science, FORTH, Greece 2School of Computer Science, Universidad Politécnica de Madrid, and IMDEA Software Institute, Madrid, Spain

Deriving Specifications for Composite Web Services

Izmir, Turkey

OutlineIntroduction• Web Services and Formal Specification• The Need for Service Specifications• The Special Case of Services

Deriving Composite Service Specifications• Motivating Example• Specification Semantics• Calculating Pre- and Post- Conditions

Handling Special Cases• Loops• Asynchronous Execution

Conclusions & Future Work

2

Web Services and Formal Specification (1)

• In recent years a multitude of ways of delivering applications via the Web have been proposed– Traditional SOAP-based Web Services

• Semantic Web Services

– RESTful Web Services• Web APIs• Linked Data Services (LIDS)

• Regardless of their characteristics, all Web services need to be described, in order to be discovered and, possibly, composed.

3Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis

Web Services and Formal Specification (2)

• Web Service Description deals with specifying all the information needed to access and use a service– Should contain both functional and non-functional

aspects– May contain information on the internal processes of

the service (especially if it is a composite service)– Should be written in a formal, well-defined

specification language to allow for automated processing and verification

– Should facilitate the discovery and composition of services


The Need for Service Specifications (1)

• Service specifications can be employed for– Constructing a service based on a set of

requirements, provided as a specification

– Checking conformance of an existing service to a specification agreed upon by the parties involved, promoting trust between digital society partners

– Auditing processes that check third party or legacy code conformance


The Need for Service Specifications (2)

• Service specifications can be employed for– Verification techniques: checking whether a

service satisfies a property (e.g. termination or temporal ordering of actions)

– Evaluation of the results of service adaptation or service evolution

– Detecting inconsistencies in a composite service


The Special Case of Services

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






8

Motivating Example (1)

• Employing services in order to facilitate the process of obtaining government-issued documents– Users login to the system and fill in a request form– Some documents require a fee, so a payment

form may need to be filled in too– The payment process is executed only after both

forms are complete and valid– In some cases, the resulting documents need to

be digitally certified9Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis


• Initially, we have composite service S1, implemented according to specification T1.

• T1 is augmented to T2 in order to include the capability of document certification

• S1 evolves to S2 in order to meet the new requirements• We need to derive the specification for S2 in order to check if it

conforms to T210Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis


11

Specification Semantics

• A service specification with preconditions P and postconditions Q, can be expressed in first-order logic as:

– si and so denote the states before and after execution of the particular service respectively

– x and y are vector variables representing the input fed to the service and the returned output

– P and Q can be expected to be safe approximations of the actual code specifications

• Given similar specifications for the services participating in a composition, we want to construct an equivalent specification for the composite service as a whole


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 equivalents13Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis

Calculating Pre- And Post-Conditions (1)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 (2)AND-Split/AND-Join

• The diverging branches execute concurrently and both activities need to complete

• The derived specification is:


Calculating Pre- And Post-Conditions (3)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 (4)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 (5)Conditional Constructs

• The truth value of condition C determines which of A and B is going to be executed The derived specification is:


Calculating Pre- And Post-Conditions (6)Conditional Constructs


Back to the Motivating Example

20

• Using the specifications calculated previously, we gradually derive the following specification for this example composite process :





21

Current ResultsThe 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

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


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






25

Conclusions

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

• 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


Future Work

• An implementation of the proposed approach is currently underway

• Further issues involve exploring loop invariant generation techniques and applying simplification techniques to the derived specifications

• The work is planned to be integrated in a novel specification language for Web services and service compositions, focusing on eliminating the well-known frame, ramification and qualification problems


Questions

28George BaryannisA Novel Language for the Specification of Web Services and Service Compositions

deriving specifications for composite web services

Documents