S-CUBE LP: Formal Specifications for Services and Service Compositions

www.s-cube-network.eu

S-Cube Learning Package

Service Specifications:

Formal Specifications for Services and Service Compositions

University of Crete (UoC),

Universidad Politecnica de Madrid (UPM)

George Baryannis and Dimitris Plexousakis, UoC

Manuel Carro, UPM

Learning Package Categorization

S-Cube

Formal Models and Languages for

QoS-Aware Service Compositions

Models and Mechanisms for

Coordinated Service Compositions

Formal Specifications for Services

and Service Compositions

Learning Package Overview

Problem Description

Addressing the Frame Problem in Service Specifications

Automatic Derivation of Composite Specifications

Discussion and Summary

The Need for Service Specifications (1)

Formal specifications promote and facilitate the reusability of

services and service compositions

– Especially important in the case of legacy services, where it is crucial

to have a formal representation of the service that can be reasoned

with

– In the case of service compositions, specifications abstract away the

composition method and use all composite services in the same way

regardless of whether they’ve been composed using Java, C#, BPEL,

MS Workflow etc.

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

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

The Need for Service Specifications (2)

Service specifications also enable the following:

– construction of a service based on a set of requirements agreed upon

by the parties involved

– checking that a service meets a set of requirements

– service verification techniques

– detection of inconsistencies to decide whether a set of services is

composable

Complete formal specifications are crucial for both

– Service providers, to advertise more effectively the offered services

– Service consumers, to make informed choices by knowing the exact

way in which a service is expected to perform

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

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

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

Issues involving Service Specifications (1)

Service Specifications are usually based on logic-based

knowledge representation for the description of service

functionality (Inputs, Outputs, Preconditions and Effects,

collectively known as IOPEs) (e.g. in OWL-S or WSMO)

This makes them vulnerable to three well-known problems

– The Frame Problem: how to state in a succinct way that nothing else

changes, except when stated otherwise

– The Ramification Problem: how to represent and infer information

about the knock-on and indirect effects of an action or an event

– The Qualification Problem: how to list all preconditions that must be

satisfied for an action to have a desired effect and how to update them

when new statements become part of our knowledge

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

Issues involving Service Specifications (2)

A composite service should be delivered to consumers in the

same way as an atomic one

– Specifications for composite services should be available, based on

the specifications of the services that take part in the composition

No service description frameworks or service composition

approaches attempt to derive a complete specification of the

inputs, outputs, preconditions and effects (IOPEs) that should

be provided to a service consumer

Both issues (and, as it will become obvious, the solutions we

propose) share a common basis: the use of logic

representation to describe a Web service in a richer, more

flexible way and one that can be reasoned with


Problem Description




A Motivating Example (1)

Typical case of an online shop:

Let’s focus on the Execute Order task, which may

include the following subtasks:



The three subtasks with the exception of the package and

delivery can be performed by Web Services

A Web Service that is tasked with the money withdrawal

should:

– Check before execution that the credit card is valid and that the

account has enough money

– Withdraw the money and check that the balance is still positive

– Ban the credit card if the daily withdrawal limit (DL) has been reached

– If we’re close to the limit (less than an amount of W), warn the client,

otherwise don’t



Encoding the service description using the precondition/postcondition notation:

PRECONDITIONS:

Valid(creditCard, account)

balance(account) ≥ A

POSTCONDITIONS:

balance′(account) = balance(account) – A

balance′(account) ≥ 0

withdrawalTotal′(day, account)=

withdrawalTotal(day, account) + A

withdrawalTotal′(day, account) ≥ DL

¬Valid′ (creditCard, account)

(withdrawalTotal′(day, account) < DL

DL – withdrawalTotal′(day, account) ≤ W)

Warn′ (creditCard, account)

(withdrawalTotal′(day, account) < DL DL – withdrawalTotal′(day, account) > W)

¬ warn′ (creditCard, account)


Note the use of

primed/unprimed

predicates to denote

when the predicate

is evaluated:

balance is evaluated

before execution

while balance′

afterwards


This specification is not complete:

– We can’t prove that no other accounts or credit cards are affected by

the service execution

We need to add frame axioms that explicitly state that nothing else

changes. The complete specification is shown on the next slide.

As it will become obvious, including frame axioms

– becomes rather challenging, especially when handling complex specifications

– results in an even more complicated and lengthy specification that would

make computing formal proofs based on it a challenging task



POSTCONDITIONS:

balance′(account) = balance(account) – A balance′(account) ≥ 0

x[x ≠ account balance(x) = balance′(x)]

withdrawalTotal′(day, account) = withdrawalTotal(day, account) + A

x,y[x ≠ day, y ≠ account withdrawalTotal′(x,y) = withdrawalTotal(x,y)]

withdrawalTotal′(day, account) ≥ DL ¬ Valid(creditCard, account)

x,y[x ≠ creditCard y ≠ account Valid(x,y) ≡ Valid′(x,y)] x,y[Warn(x,y) ≡ Warn′(x,y)]

(withdrawalTotal′(day, account) < DL DL – withdrawalTotal′(day, account) ≤ W)

Warn′(creditCard, account)

x,y[x ≠ creditCard y ≠ account Warn(x,y) ≡ Warn′(x,y)] x,y[Valid (x,y) ≡ Valid′(x,y)]

(withdrawalTotal′(day, account) < DL DL – withdrawalTotal′(day, account) > W) ¬





The effects of the frame problem aggravate in the case of composite service specifications.

Suppose we have the following complete specifications for two services that handle the wish list and recommendations update subtasks.

– The Completed predicate denotes that the item contained in that particular order has been delivered to the buyer

– The Included predicate denotes that the second argument (the item) is contained in the first argument (the wish list or the recommendations list)

PRE1: Completed(order, item) Included(buyersWishList, item)

POST1: ¬Included′(buyersWishList, item)

x, y [Completed(x, y) ≡ Completed′(x, y)]

x, y [x ≠ buyersWishList y ≠ item Included(x, y) ≡ Included′(x, y)]

PRE2: Completed(order, item)

¬Included(buyersRecoms, associatedItem)

POST2: Included′(buyersRecoms, associatedItem)


x, y [x ≠ buyersRecoms y ≠ associatedItem

Included(x, y) ≡ Included′(x, y)]

A Motivating Example: Service Composition (1)


Suppose now that we want a service that executes an order for all items contained in it. We may compose the 3 services we specified in the previous slides:

• Let’s describe the parallel composition of the wish list and recommendations update services in terms of its preconditions and postconditions



Parallel Composition of Wish List and Recommendations

Update Services


Included(buyersWishList, item)


¬ Included(buyersRecoms, associatedItem)

The preconditions of the composite service are derived from

the preconditions of the two services that participate in the

composition



Parallel Composition of Wish List and Recommendations

Update Services

PRE: Completed(order, item)



Postconditions must be derived similarly, by considering the

postconditions of the participating services (more on

deriving composite specifications in the following section)



Parallel Composition of Wish List and Recommendations Update Services




POST1: ¬Included′(buyersWishList, item)

x, y [x ≠ buyersWishList y ≠ item



POST2: Included′(buyersRecoms, associatedItem)






Parallel Composition of Wish List and Recommendations Update Services




POST: ¬Included′(buyersWishList, item)

Included′(buyersRecoms, associatedItem)







The highlighted

postconditions are

inconsistent (they

cannot be true

at the same time)


The frame problem may indeed make Web Service

specifications

– lengthier, more complex

– inconsistent, in the case of Web Service composition

To solve it, we adopt the solution of Explanation Closure

axioms

– Has been applied to procedure specifications, conceptually close to

Web Service specifications

– Is expressed in first-order predicate logic, suitable for current Semantic

Web Service frameworks such as OWL-S

Addressing the Frame Problem (1)


Frame Axioms: Procedure-oriented perspective

– State what predicates or functions each procedure (service) does not

change

Explanation Closure Axioms: State-oriented perspective

– State which procedures (services) change each predicate or function

– Extend first-order predicate logic with:

- Special predicate Occur, of arity 1 and special variable α

- Occur(α) is true iff the service denoted by variable α has executed

successfully

– Explanation Closure Axioms are also known as Change Axioms

Addressing the Frame Problem (2)


Let’s revisit the money withdrawal service specification from the example:

POSTCONDITIONS:


x[x ≠ account balance(x) = balance′(x)]

withdrawalTotal′(day, account) = withdrawalTotal(day, account) + A

x,y[x ≠ day, y ≠ account withdrawalTotal′(x,y) = withdrawalTotal(x,y)]

withdrawalTotal′(day, account) ≥ DL ¬ Valid(creditCard, account)

x,y[x ≠ creditCard y ≠ account Valid(x,y) ≡ Valid′(x,y)] x,y[Warn(x,y) ≡ Warn′(x,y)]

(withdrawalTotal′(day, account) < DL DL – withdrawalTotal′(day, account) ≤ W)



(withdrawalTotal′(day, account) < DL DL – withdrawalTotal′(day, account) > W) ¬



Expressing Change Axioms (1)


We need to provide a change axiom for each distinct function/predicate, stating whice service execution leads to it changing

Some postconditions may be removed since their knowledge is captured by the change axioms

POSTCONDITIONS:


αx[balance(x) ≠ balance′(x) Occur(a)

a = MoneyWithdrawal(x, A)]

αx,y[Valid(x,y) ≢ Valid′(x,y) Occur(a)

a = MoneyWithdrawal(x, A) withdrawalTotal′(x) ≥ DL]

αx,y[Warn(x,y) ≢ Warn′(x,y) Occur(a)

a = MoneyWithdrawal(x, A)

DL – withdrawalTotal′(x) ≤ W]


MoneyWithdrawal(x, A)

represents the

execution of the

Money Withdrawal

service, to withdraw

an amount A

from account x


Now let’s deal with the parallel composition specification from the example:




POST: ¬Included(buyersWishList, item)

Included(buyersRecoms, associatedItem)


Included(x, y) ≡ Included(x, y)]


Included(x, y) ≡ Included(x, y)]

x, y [Completed(x, y) ≡ Completed(x, y)]



A change axiom is provided for each predicate and redundant

postconditions are removed:




POST: α x, y [Ιncluded (x, y)

¬ Ιncluded(x, y) Occur(α)]

α = WishListUpdate(x, y) α = RecomsUpdate(x, y)

α x,y [Completed(x, y) ¬Completed(x, y)

Occur(α)] false



In OWL-S, logic formulas and rules are expressed in the

Semantic Web Rule Language (SWRL)

– For change axioms, we use an extension of SWRL, SWRL-FOL

– SWRL-FOL provides constructs to express all kinds of first-order logic

formulas

- Occur can be expressed as a unary predicate which has the

meaning that its argument belongs to a certain OWL class.

- The variable α can be expressed as an individual variable.



Given a service specification in OWL-S, we want to devise an

algorithm to produce the change axioms needed for the

specification to be complete

– The algorithm must handle both atomic and composite service

specifications

– A change axiom must be added, for each predicate contained in the

specifications

– A predicate’s value should be considered changed by the service

execution, if

- It is negated in a precondition but not in a postcondition

- It is negated in a postcondition but not in a precondition

Automatically Producing Change Axioms (1)

A Motivating Example (1) Automatically Producing Change Axioms (2)


Problem Description




Another Motivating Example (1)

Based on the E-Government case study of S-Cube, we have

the following example: citizens submit applications to request

some government-related service, such as obtaining

government-issued documents.

The process below is followed:

The numbers denote the states before and after each

particular task in the process.

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

Another Motivating Example (2)

A possible specification for atomic services that implement the

tasks in the example process is:

Given these specifications and the description of the

composition schema, we want to derive a specification for the

composite service that implements the process

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

What constitutes a Specification for a Composite Service?

The composite specification is directly linked to the

composition schema and the way the participating services

are orchestrated

– Which part of the participating services’ specifications should be

exposed?

- The complete specifications of all participating services?

- Only the preconditions of the services whose inputs are exposed

(and the postconditions of the services whose outputs are

exposed)?

The first choice may lead to over-specification while the

second may do just the opposite

We propose a derivation process that is based on structural

induction and attempts to construct the composite

specification using a bottom-up approach.

Given these specifications and the description of the

composition schema, we want to derive a specification for the

composite service that implements the process

Calculating Pre/Postconditions for Basic Control Constructs (1)

A first-order logic semantics for a service specification with

regard to its preconditions P and postconditions Q is:

where x and y are input and output variables, while si and so

denote the state before service execution and the state after a

successful execution, respectively

In order to be able to apply structural induction on any given

composition schema we need to express such specification

statements for all basic composition control constructs

Let’s consider the case of sequential composition

For the two services in the figure, the

following holds:

This is equivalent to:

However, in this equation internal variable z is exposed in the

precondition, which means it is not externally checkable which is

not desirable

– We can eliminate this using the postcondition of A:


Sequence

Now let’s consider the case of conditionals.

If C is true then A is executed,

otherwise B is executed. Hence:

From this equation, we can deduce the following:

The next slide contains a table with pre/postconditions for all basic

control constructs. The Prover9 theorem prover was used to check

all necessary proofs.


Conditional


Conditional Split/Join Constructs

Sequence

Deriving a Composite Specification (1)

Using the previous slide and the composition schema for the

process of the motivating example we can derive a

specification for the composite process

1. The parallel execution of CheckRequest and CheckPayment

can be specified as follows:

2. The sequence of Login and the above service leads to:


3. Adding the Payment service to the sequence leads to:

4. The conditional execution of

CreateCertified and

CreateUncertified is specified

with the equation on the right:


5. Combining specifications in steps 3 and 4 to form the

complete sequence of the process we result in the final

composite specification:


Problem Description




Discussion (1)

The approaches described in this presentation enable the

creation of service specifications that

– are free of the effects of the frame problem

– Effectively capture a composite process comprising basic control

constructs

Both approaches enrich service specifications for both atomic

and composite services and can, in principle, be combined in

a single Web service specification that possesses both of the

aforementioned characteristics.

Discussion (2)

There are several research directions that complement the

work presented. For instance, the closely associated

ramification and qualification problems pose issues such as:

– How de we include ramifications (knock-on and indirect effects) in a

specification?

– What if the solution to the frame problem precludes any indirect

effects?

– How is new knowledge assimilated in an existing specification? What

if it leads to an inconsistent specification?

Discussion (3)

As far as deriving composite specifications is concerned,

some issues worth exploring are:

– Simplifying the resulting specification by applying known equivalences

or by exploiting specific knowledge on the particular composite service

– Supporting more complex control constructs such as loops which may

involve approximating loop invariants for the case of Web services and

determining when the loop terminates

– Handling asynchronous calls, where the client invokes a service but

does not wait for its response, which may lead to differences in the

evaluation of postconditions, depending on when the response is

received.

Summary

The frame problem in service specifications can be addressed

using the approach of change axioms

Change axioms can be used to provide complete descriptions for

atomic and composite services containing all major composition

schemas and an algorithm for the automatic production of change

axioms was presented

As far as deriving specifications is concerned, the presented

approach attempts to construct the specification by using structural

induction based on derivation rules defined for most fundamental

control constructs

The resulting specification can be used to formally describe the

composite service in terms of its preconditions and postconditions

without requiring any knowledge of the internals of the composition,

allowing for an actual ”black box” view of the whole process.

Acknowledgements

The research leading to these results has

received funding from the European

Community’s Seventh Framework

Programme [FP7/2007-2013] under grant

agreement 215483 (S-Cube).

© Philipp Leitner

S-CUBE LP: Formal Specifications for Services and Service Compositions

Technology

Transcript of S-CUBE LP: Formal Specifications for Services and Service Compositions