Date post: | 03-Dec-2014 |
Category: |
Technology |
Upload: | virtual-campus |
View: | 560 times |
Download: | 1 times |
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.
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
Learning Package Overview
Problem Description
Addressing the Frame Problem in Service Specifications
Automatic Derivation of Composite Specifications
Discussion and Summary
A Motivating Example (1)
Typical case of an online shop:
Let’s focus on the Execute Order task, which may
include the following subtasks:
A Motivating Example (1)
A Motivating Example (1)
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
A Motivating Example (2)
A Motivating Example (1)
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)
A Motivating Example (3)
Note the use of
primed/unprimed
predicates to denote
when the predicate
is evaluated:
balance is evaluated
before execution
while balance′
afterwards
A Motivating Example (1)
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
A Motivating Example (4)
A Motivating Example (1)
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 (5)
A Motivating Example (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)]
A Motivating Example: Service Composition (1)
A Motivating Example (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
A Motivating Example: Service Composition (2)
A Motivating Example (1)
Parallel Composition of Wish List and Recommendations
Update Services
PRE1: Completed(order, item)
Included(buyersWishList, item)
PRE2: Completed(order, item)
¬ Included(buyersRecoms, associatedItem)
The preconditions of the composite service are derived from
the preconditions of the two services that participate in the
composition
A Motivating Example: Service Composition (3)
A Motivating Example (1)
Parallel Composition of Wish List and Recommendations
Update Services
PRE: Completed(order, item)
Included(buyersWishList, item)
¬ Included(buyersRecoms, associatedItem)
Postconditions must be derived similarly, by considering the
postconditions of the participating services (more on
deriving composite specifications in the following section)
A Motivating Example: Service Composition (3)
A Motivating Example (1)
Parallel Composition of Wish List and Recommendations Update Services
PRE: Completed(order, item)
Included(buyersWishList, item)
¬ Included(buyersRecoms, associatedItem)
POST1: ¬Included′(buyersWishList, item)
x, y [x ≠ buyersWishList y ≠ item
Included(x, y) ≡ Included′(x, y)]
x, y [Completed(x, y) ≡ Completed′(x, y)]
POST2: Included′(buyersRecoms, associatedItem)
x, y [x ≠ buyersRecoms y ≠ associatedItem
Included(x, y) ≡ Included′(x, y)]
x, y [Completed(x, y) ≡ Completed′(x, y)]
A Motivating Example: Service Composition (3)
A Motivating Example (1)
Parallel Composition of Wish List and Recommendations Update Services
PRE: Completed(order, item)
Included(buyersWishList, item)
¬ Included(buyersRecoms, associatedItem)
POST: ¬Included′(buyersWishList, item)
Included′(buyersRecoms, associatedItem)
x, y [x ≠ buyersWishList y ≠ item
Included(x, y) ≡ Included′(x, y)]
x, y [x ≠ buyersRecoms y ≠ associatedItem
Included(x, y) ≡ Included′(x, y)]
x, y [Completed(x, y) ≡ Completed′(x, y)]
A Motivating Example: Service Composition (3)
The highlighted
postconditions are
inconsistent (they
cannot be true
at the same time)
A Motivating 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
Addressing the Frame Problem (1)
A Motivating 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
Addressing the Frame Problem (2)
A Motivating Example (1)
Let’s revisit the money withdrawal service specification from the example:
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)]
Expressing Change Axioms (1)
A Motivating Example (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:
balance′(account) = balance(account) – A balance′(account) ≥ 0
α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]
Expressing Change Axioms (2)
MoneyWithdrawal(x, A)
represents the
execution of the
Money Withdrawal
service, to withdraw
an amount A
from account x
A Motivating Example (1)
Now let’s deal with the parallel composition specification from the example:
PRE: Completed(order, item)
Included(buyersWishList, item)
¬ Included(buyersRecoms, associatedItem)
POST: ¬Included(buyersWishList, item)
Included(buyersRecoms, associatedItem)
x, y [x ≠ buyersWishList y ≠ item
Included(x, y) ≡ Included(x, y)]
x, y [x ≠ buyersRecoms y ≠ associatedItem
Included(x, y) ≡ Included(x, y)]
x, y [Completed(x, y) ≡ Completed(x, y)]
Expressing Change Axioms (3)
A Motivating Example (1)
A change axiom is provided for each predicate and redundant
postconditions are removed:
PRE: Completed(order, item)
Included(buyersWishList, item)
¬ Included(buyersRecoms, associatedItem)
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
Expressing Change Axioms (4)
A Motivating Example (1)
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.
Expressing Change Axioms (5)
A Motivating Example (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 (1)
A Motivating Example (1) Automatically Producing Change Axioms (2)
Learning Package Overview
Problem Description
Addressing the Frame Problem in Service Specifications
Automatic Derivation of Composite Specifications
Discussion and Summary
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.
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:
Calculating Pre/Postconditions for Basic Control Constructs (2)
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.
Calculating Pre/Postconditions for Basic Control Constructs (3)
Conditional
Calculating Pre/Postconditions for Basic Control Constructs (4)
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:
Deriving a Composite Specification (2)
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:
Deriving a Composite Specification (3)
5. Combining specifications in steps 3 and 4 to form the
complete sequence of the process we result in the final
composite specification:
Learning Package Overview
Problem Description
Addressing the Frame Problem in Service Specifications
Automatic Derivation of Composite Specifications
Discussion and Summary
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