Policy-based reasoning for smart web service interaction

1. Policy-based reasoning for smart web service interaction Federico Chesani, Paola Mello, Marco Montali, Paolo Torroni Marco Alberti, Marco Gavanelli, Evelina Lamma

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. 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? • WAVe Architecture • Framework • Modeling • Semantics • Verification Example

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. 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: alicetries directly to obtain the device from eShop, e.g. by sending a request • Reasoning about policies: alicetries first to consider whether eShop’s policies are compatible with her own ones

6. Example:alice & eShop (cont’d) • Reasoning about policies: possible steps • alice requests from eShop its policies regarding the sales of device • eShop composes a set of rules related to alice’s request (policies) • 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) • at a later point, alice and eShop may engage in such a transaction about device WAVe

7. WAVe Framework WAVe Architecture

8. WAVeFramework • Enables reasoning about possible events • Separates private knowledge(Gws & KBws) from public knowledge (policies/ICws )

9. WAVeFramework • 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: Pws • Pws: <KBws, Ews, ICws> • ICws: forward rules, Body → Head with disjunctions in the Head • Gws: the goal of a web service (e.g. have device)

10. Modelling in WAVeGws • Sample alice goal: “to have device at time 50.” have( alice, device, 50 ) .

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

12. Modelling in WAVeICws (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 ), Ts ) → E( alice, eShop, pay( Item, cc ), Tcc )  Tcc < Ts  E( alice, eShop, pay( Item, cash ), Tca )  Tca < Ts  E( alice, eShop, pay( Item, cheque ), Tch )  Tch < Ts .

13. Modelling in WAVeICws (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 ), Td )  H( alice, eShop, pay( Item, How ), Tp )  Tp < Td  How :: [cc, cash, cheque] → inStock( Item )  H( eShop, alice, deliver( Item ), Td )  not inStock( Item )  H( eShop, alice, refund, Td ).

14. abductive answer Semantics of WAVe(abductive answer, HAP  EXP  ) • Declarative semantics: given Gws , KBws , ICws , andICws’ , find HAP  EXP  , where: • HAP is a conjunction of H atoms • EXPis a conjunction of E atoms • is a conjunction of unknowns that are neither E nor H atoms such that KBws HAP  EXP  ⊨ Gws KBws HAP  EXP  ⊨ ICws  ICws’

15. Semantics of WAVe(entailment, ⊨) • Possible belief sets semantics for Abductive Extended Disjunctive Logic Programs (AEDP)1 • Based on split programs • With a new notion of A-minimality 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) } AEDP: { E(p)  H(p)  E(p), goal  E(p)} 1Sakama & Inoue, Journal of Logic Programming 44(2000):75-100

16. Semantics of WAVe(A-minimality) • Given an AEDP  = <P, A>, 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: S1 : { E(p), goal } S2 : { H(p), E(p), goal }

17. Semantics of WAVe(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. Verification in WAVe ( alice ) g  have( alice, device, 50 ). EXP0 = { E( eShop, alice, deliver( device ), Td )  Td ≤50 } EXP1 = { E( eShop, alice, deliver( device ), Td )  Td ≤50  E( alice, eShop, pay( device, How ), Tp )  Tp <Td How :: [cc, cash, cheque] }

19. Verification in WAVe ( alice ) g  have( alice, device, 50 ). EXP0 = { E( eShop, alice, deliver( device ), Td )  Td ≤50 } EXP1 = { E( eShop, alice, deliver( device ), Td )  Td ≤50  E( alice, eShop, pay( device, cc ), Tp )  Tp <Td } EXP2 = { E( eShop, alice, deliver( device ), Td )  Td ≤50  E( alice, eShop, pay( device, cc ), Tp )  Tp <Td  E( eShop, alice, give_guarantee, Tg )  Tg <Tp }

20. C Verification in WAVe EXP2 = { E( eShop, alice, deliver( device ), Td )  Td ≤50  E( alice, eShop, pay( device, cc ), Tp )  Tp <Td  E( eShop, alice, give_guarantee, Tg )  Tg <Tp } HAP3 = { H( eShop, alice, give_guarantee, Tg )  Tg <Tp } HAP4 = { H( eShop, alice, give_guarantee, Tg )  Tg <Tp  H( alice, eShop, pay( device, cc ), Tp )  Tp <Td } HAP5 = { H( eShop, alice, give_guarantee, Tg )  Tg <Tp  H( alice, eShop, pay( device, cc ), Tp )  Tp <Td  H( eShop, alice, deliver( device ), Td )  Td <50} 5 = { inStock( device ) }

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? • WAVe 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. 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 WAVe • Selection/filtering of policies (point 2.) • Use of the output of WAVe by web services (point 4.) • Exchange of policies between web services thanks for your attention!