1. ALMA MATER STUDIORUM UNIVERSITY OF BOLOGNA UNIVERSITY OF FERRARA Policy-based reasoning for smart web service interaction Federico Chesani, Paola Mello, Marco Montali, Paolo Torroni Marco Alberti, Marco Gavanelli, Evelina Lamma

2. 2 MOTIVATION  Service Oriented Computing  off-the-shelf solutions (web services)  composition of w.s. into new applications  Many advantages  rapid prototyping  complex applications from simple elements  Some problems  decreasing lifetime of software  need to cope with proliferation of new services  difficult to remain competitive

3. 3 FOCUS How can we dynamically understand if two web services can inter-operate, without having them a-priori knowledge of each other’s capabilities, but by reasoning about policies exchanged at run-time?  WAV e Architecture  Framework  Modeling  Semantics  Verification Example

4. 4 Example: alice & eShop  alice: “I need to obtain a device. I can obtain an item if it is delivered to me. I can only pay by credit card. And before I use my credit card to pay a shop, I need to see evidence of the shop’s BBB membership.”  eShop: “I have such a device in stock. I can deliver an item, if I have it in stock, and after I get paid for it. I accept credit card payments, cash, and cheques. I am a member of the BBB, and I can show evidence of it.”

5. 5 Example: alice & eShop (cont’d)  Open problems  How does alice know that eShop’s policies are compatible with her own ones?  In case they are compatible, how can alice/eShop engage in successful interaction?  Possible solutions  Trial and error: alice tries directly to obtain the device from eShop, e.g. by sending a request  Reasoning about policies: alice tries first to consider whether eShop’s policies are compatible with her own ones

6. 6 Example: alice & eShop (cont’d)  Reasoning about policies: possible steps 1.alice requests from eShop its policies regarding the sales of device 2.eShop composes a set of rules related to alice’s request (policies) 3.alice reasons on her goal, her own policies, and eShop’s policies, and concludes that there exists a possible transaction between them which makes her achieve her goal (to obtain device) 4.at a later point, alice and eShop may engage in such a transaction about device WAV e

7. 7 WAV e Architecture WAVe Framework

8. 8  Enables reasoning about possible events  Separates private knowledge ( G ws & KB ws ) from public knowledge (policies/ IC ws )

9. 9 WAV e Framework  Events: observable behaviour  generated by self (ws can make them happen): H  externally generated (ws “expects” them): E  H, E: Hypotheses on possibly happening events  WS ALP interface behaviour specification: P ws  P ws :  IC ws : forward rules, Body → Head with disjunctions in the Head  G ws : the goal of a web service (e.g. have device)

10. 10 Modelling in WAV e G ws  Sample alice goal: “to have device at time 50.” have( alice, device, 50 ).

11. 11 Modelling in WAV e KB ws  Sample clause in alice knowledge base: “alice haa an item at time T, if eShop delivers it to her at a time T d no later than T.” have( alice, Item, T )  E( eShop, alice, deliver( Item ), T d )  T d ≤ T.

12. 12 Modelling in WAV e IC ws (1)  Sample eShop policy (1): “if a customer wishes to buy an item, (s)he should pay it either by credit card, or by cash, or by cheque.” E( eShop, alice, deliver( Item ), T s ) → E( alice, eShop, pay( Item, cc ), T cc )  T cc < T s  E( alice, eShop, pay( Item, cash ), T ca )  T ca < T s  E( alice, eShop, pay( Item, cheque ), T ch )  T ch < T s.

13. 13 Modelling in WAV e IC ws (2)  Sample eShop policy (2): “if a customer wishes to buy an item, and (s)he has paid it either by credit card, or by cash, or by cheque, then eShop will deliver the item […].” E( eShop, alice, deliver( Item ), T d )  H( alice, eShop, pay( Item, How ), T p )  T p < T d  How :: [cc, cash, cheque] → inStock( Item )  H( eShop, alice, deliver( Item ), T d )  not inStock( Item )  H( eShop, alice, refund, T d ).

14. 14 Semantics of WAV e (abductive answer, HAP  EXP   )  Declarative semantics: given G ws, KB ws, IC ws, and IC ws’, find HAP  EXP  , where:  HAP is a conjunction of H atoms  EXP is a conjunction of E atoms   is a conjunction of unknowns that are neither E nor H atoms such that KB ws  HAP  EXP   ⊨ G ws KB ws  HAP  EXP   ⊨ IC ws  IC ws’ abductive answer

15. 15 Semantics of WAV e (entailment, ⊨ )  Possible belief sets semantics for Abductive Extended Disjunctive Logic Programs (AEDP) 1  Based on split programs  With a new notion of A -minimality 1 Sakama & Inoue, Journal of Logic Programming 44(2000):75-100 AEDP: { E(p)  H(p)  E(p), goal  E(p) } split programs: s.p.1: { E(p)  E(p), goal  E(p) } s.p.2: { H(p)  E(p), goal  E(p) } s.p.3: { E(p)  E(p), H(p)  E(p), goal  E(p) }

16. 16 Semantics of WAV e ( A -minimality)  Given an AEDP  =, a possible belief set S of  is a possible model of the DLP P  E, where E  A.  A possible belief set S is A -minimal iff there is no possible belief set T for the same split program such that T  A  S  A AEDP: { E(p)  H(p)  E(p), goal  E(p) } A-minimal possible belief sets: S 1 : { E(p), goal } S 2 : { H(p), E(p), goal }

17. 17 Semantics of WAV e (possible interactions)  A possible interaction between two web services ws and ws’ about a goal G is an A -minimal abductive answer HAP  EXP    A possible interaction between two web services ws and ws’ achieving a goal G is a possible interaction about G, HAP  EXP   s.t.: HAP  EXP ⊨ E( X, Y, Action, T )  H( X, Y, Action, T )  Operational semantics: sound and complete extension of SCIFF (see article)

18. 18 Verification in WAV e ( alice ) g  have( alice, device, 50 ). EXP 0 = { E( eShop, alice, deliver( device ), T d )  T d ≤ 50 } EXP 1 = { E( eShop, alice, deliver( device ), T d )  T d ≤ 50  E( alice, eShop, pay( device, How ), T p )  T p < T d  How :: [cc, cash, cheque] }

19. 19 Verification in WAV e ( alice ) g  have( alice, device, 50 ). EXP 0 = { E( eShop, alice, deliver( device ), T d )  T d ≤ 50 } EXP 1 = { E( eShop, alice, deliver( device ), T d )  T d ≤ 50  E( alice, eShop, pay( device, cc ), T p )  T p < T d } EXP 2 = { E( eShop, alice, deliver( device ), T d )  T d ≤ 50  E( alice, eShop, pay( device, cc ), T p )  T p < T d  E( eShop, alice, give_guarantee, T g )  T g < T p }

20. 20 Verification in WAV e EXP 2 = { E( eShop, alice, deliver( device ), T d )  T d ≤ 50  E( alice, eShop, pay( device, cc ), T p )  T p < T d  E( eShop, alice, give_guarantee, T g )  T g < T p } HAP 3 = { H( eShop, alice, give_guarantee, T g )  T g < T p } HAP 4 = { H( eShop, alice, give_guarantee, T g )  T g < T p  H( alice, eShop, pay( device, cc ), T p )  T p < T d } HAP 5 = { H( eShop, alice, give_guarantee, T g )  T g < T p  H( alice, eShop, pay( device, cc ), T p )  T p < T d  H( eShop, alice, deliver( device ), T d )  T d < 50 }  5 = { inStock( device ) } C

21. 21 CONCLUSION How can we dynamically understand if two web services can inter-operate, without having them a- priori knowledge of each other’s capabilities, but by reasoning about policies exchanged at run- time?  WAV e Architecture (layers: RIF, KR, reasoning)  Framework (ALP+events)  Modeling (alice & eShop’s policies, goals and KB)  Semantics (based on AEDP: A-minimal abductive answers achieving a goal)  Verification (alice’s achievable goal)

22. 22 OTHER WORK  Related Work  Huge literature on architectures, logics, and languages for the semantic web  Work on policies, e.g. Bradshaw et al. and Finin et al.  Work on agent protocols, e.g. Singh et al. and SCIFF  Proof-procedures and semantics for ALP  Future Work  Extensive empirical evaluation of WAV e  Selection/filtering of policies (point 2.) point 2.point 2.  Use of the output of WAV e by web services (point 4.) point 4.point 4.  Exchange of policies between web services thanks for your attention!