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

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

www.s-cube-network.eu

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.

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

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

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

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:
Note the use of
Valid(creditCard, account) 
balance(account) ≥ A
primed/unprimed
POSTCONDITIONS: predicates to denote
balance′(account) = balance(account) – A  when the predicate
balance′(account) ≥ 0  is evaluated:
withdrawalTotal′(day, account)= balance is evaluated
withdrawalTotal(day, account) + A before execution
withdrawalTotal′(day, account) ≥ DL  while balance′
¬Valid′ (creditCard, account)  afterwards
(withdrawalTotal′(day, account) < DL 
DL – withdrawalTotal′(day, account) ≤ W) 
Warn′ (creditCard, account) 
(withdrawalTotal′(day, account) < DL  DL – withdrawalTotal′(day, account) > W) 
¬ warn′ (creditCard, account)


 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)  ¬
Warn′(creditCard, account) 
x,y[x ≠ creditCard  y ≠ account Warn(x,y) ≡ Warn′(x,y)]  x,y[Valid (x,y) ≡ Valid′(x,y)]

A Motivating Example:
Service Composition (1)
 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 [Completed(x, y) ≡ Completed′(x, y)] 
x, y [x ≠ buyersRecoms  y ≠ associatedItem 
Included(x, y) ≡ Included′(x, y)]

 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) 
Included(buyersWishList, 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 
Included(x, y) ≡ Included′(x, y)] 
POST2: Included′(buyersRecoms, associatedItem) 

Parallel Composition of Wish List and Recommendations Update Services

POST: ¬Included′(buyersWishList, item)  The highlighted
postconditions are
Included′(buyersRecoms, associatedItem)  inconsistent (they
x, y [x ≠ buyersWishList  y ≠ item  cannot be true
at the same time)

A Motivating the Frame Problem (1)
Addressing Example (1)

 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

A Motivating the Frame Problem (2)
Addressing Example (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

A Motivating Change Axioms (1)
Expressing Example (1)

 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)
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)  ¬
Warn′(creditCard, account) 
x,y[x ≠ creditCard  y ≠ account Warn(x,y) ≡ Warn′(x,y)]  x,y[Valid (x,y) ≡ Valid′(x,y)]

 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)] MoneyWithdrawal(x, A)
αx,y[Valid(x,y) ≢ Valid′(x,y)  Occur(a)  represents the
a = MoneyWithdrawal(x, A) execution of the
withdrawalTotal′(x) ≥ DL] Money Withdrawal
αx,y[Warn(x,y) ≢ Warn′(x,y)  Occur(a)  service, to withdraw
an amount A
a = MoneyWithdrawal(x, A) from account x
DL – withdrawalTotal′(x) ≤ W]

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

POST: ¬Included(buyersWishList, item) 
Included(buyersRecoms, associatedItem) 
x, y [x ≠ buyersWishList  y ≠ item 
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.

A Motivating Example (1) Change
Automatically Producing
Axioms (1)
 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 (2)

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.

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

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.

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:

Sequence

 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:

 Now let’s consider the case of conditionals.
 If C is true then A is executed,
otherwise B is executed. Hence:

Conditional
 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.


Sequence

Split/Join Constructs Conditional

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:

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

Recommandé

Recommandé

Contenu connexe

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

Similaire à S-CUBE LP: Formal Specifications for Services and Service Compositions (20)

Plus de virtual-campus

Plus de virtual-campus (20)

Dernier

Dernier (20)

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