We address the problem of synthesizing specifications for composite Web services, starting from those of their component services. Unlike related work in programming languages, we assume the definition of the component services (i.e. their code) to be unavailable --- at best, they are known by a specification which (safely) approximates their functional behavior. Within this scenario, we deduce general formula schemes to derive specifications for basic constructs such as sequential, parallel compositions and conditionals and provide details on how to handle the special cases of loops and asynchronous execution. The resulting specifications facilitate service verification and service evolution as well as auditing processes, promoting trust between the involved partners.

1. Deriving Specifications for
Composite Web Services
George Baryannis1, Manuel Carro2 and Dimitris Plexousakis1
gmparg@csd.uoc.gr manuel.carro@imdea.org dp@csd.uoc.gr
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
Izmir, Turkey

2. Outline
Introduction
• 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

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

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

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

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

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

8. Outline
Introduction
• 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
8

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

10. Motivating Example (2)
• 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 T2
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 10

11. Motivating Example (3)
11

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

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

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

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

16. 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
• The derived specification is:
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 16

17. 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
• The derived specification is:
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 17

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

19. Calculating Pre- And Post-Conditions (6)
Conditional Constructs
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 19

20. Back to the Motivating Example
• Using the specifications calculated previously, we gradually derive
the following specification for this example composite process :
20

21. Outline
Introduction
• 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
21

22. Current Results
The Case of Loops (1)
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 22

23. Current Results
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.
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 23

24. Current Results
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.
Deriving Specifications for Composite Web Services George Baryannis, Manuel Carro and Dimitris Plexousakis 24

25. Outline
Introduction
• 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
25

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

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

28. Questions
A Novel Language for the Specification of Web Services and Service Compositions George Baryannis 28