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

660 views
564 views

Published on

Published in: Technology, Economy & Finance
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
660
On SlideShare
0
From Embeds
0
Number of Embeds
101
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. 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
  2. 2. 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
  3. 3. Learning Package Overview Problem Description Addressing the Frame Problem in Service Specifications Automatic Derivation of Composite Specifications Discussion and Summary
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Learning Package Overview Problem Description Addressing the Frame Problem in Service Specifications Automatic Derivation of Composite Specifications Discussion and Summary
  9. 9. A Motivating Example (1) A Motivating Example (1) Typical case of an online shop: Let’s focus on the Execute Order task, which may include the following subtasks:
  10. 10. A Motivating Example (1) A Motivating Example (2) 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
  11. 11. A Motivating Example (1) A Motivating Example (3) Encoding the service description using the precondition/postcondition notation:PRECONDITIONS: Note the use of Valid(creditCard, account)  balance(account) ≥ A primed/unprimedPOSTCONDITIONS: 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)
  12. 12. A Motivating Example (1) A Motivating Example (4) 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
  13. 13. A Motivating Example (1) A Motivating Example (5)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)]
  14. 14. A Motivating Example (1) 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)]
  15. 15. A Motivating Example (1) A Motivating Example: Service Composition (2) 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
  16. 16. A Motivating Example (1) A Motivating Example: Service Composition (3)Parallel Composition of Wish List and Recommendations Update ServicesPRE1: 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
  17. 17. A Motivating Example (1) A Motivating Example: Service Composition (3)Parallel Composition of Wish List and Recommendations Update ServicesPRE: 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)
  18. 18. A Motivating Example (1) A Motivating Example: Service Composition (3)Parallel Composition of Wish List and Recommendations Update ServicesPRE: 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)]
  19. 19. A Motivating Example (1) A Motivating Example: Service Composition (3)Parallel Composition of Wish List and Recommendations Update ServicesPRE: Completed(order, item)  Included(buyersWishList, item)  ¬ Included(buyersRecoms, associatedItem)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) 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)]
  20. 20. 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
  21. 21. 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
  22. 22. A Motivating Change Axioms (1) Expressing 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)]
  23. 23. A Motivating Change Axioms (2) Expressing 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 axiomsPOSTCONDITIONS: balance′(account) = balance(account) – A  balance′(account) ≥ 0  α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]
  24. 24. A Motivating Change Axioms (3) Expressing 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)]
  25. 25. A Motivating Change Axioms (4) Expressing 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
  26. 26. A Motivating Change Axioms (5) Expressing 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.
  27. 27. 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
  28. 28. A Motivating Example (1)Automatically Producing ChangeAxioms (2)
  29. 29. Learning Package Overview Problem Description Addressing the Frame Problem in Service Specifications Automatic Derivation of Composite Specifications Discussion and Summary
  30. 30. 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.
  31. 31. 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
  32. 32. What constitutes a Specification for aComposite 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.
  33. 33. Calculating Pre/Postconditions forBasic 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
  34. 34. Calculating Pre/Postconditions forBasic Control Constructs (2) 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:
  35. 35. Calculating Pre/Postconditions forBasic Control Constructs (3) 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.
  36. 36. Calculating Pre/Postconditions forBasic Control Constructs (4) Sequence Split/Join Constructs Conditional
  37. 37. 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 process1. The parallel execution of CheckRequest and CheckPayment can be specified as follows:2. The sequence of Login and the above service leads to:
  38. 38. 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:
  39. 39. 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:
  40. 40. Learning Package Overview Problem Description Addressing the Frame Problem in Service Specifications Automatic Derivation of Composite Specifications Discussion and Summary
  41. 41. 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.
  42. 42. 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?
  43. 43. 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.
  44. 44. 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.
  45. 45. 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

×