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 others capabilities,
  but by reasoning about policies exchanged at
  run-time?
• WAVe Architecture
• Framework
• Modeling
• Semantics
• Verification

Example
4
Examplealice 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 shops 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
Examplealice eShop (contd)

• Open problems
• How does alice know that eShops 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 eShops policies are compatible
  with her own ones

6
Examplealice eShop (contd)

• Reasoning about policies possible steps
• alice requests from eShop its policies regarding
  the sales of device
• eShop composes a set of rules related to alices
  request (policies)
• alice reasons on her goal, her own policies, and
  eShops 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 Architecture
8
WAVe Framework

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

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

10
Modelling in WAVe Gws

• Sample alice goal to have device at time 50.
• have( alice, device, 50 ) .

11
Modelling in WAVe KBws

• 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
  lt Ts
• ? E( alice, eShop, pay( Item, cash ), Tca ) ?
  Tca lt Ts
• ? E( alice, eShop, pay( Item, cheque ), Tch ) ?
  Tch lt 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 lt
  Td
• ? How cc, cash, cheque
• ? inStock( Item ) ? H( eShop, alice, deliver(
  Item ), Td )
• ? not inStock( Item ) ? H( eShop, alice,
  refund, Td ).

14
Semantics of WAVe(abductive answer, HAP ? EXP ?
?)

• Declarative semantics given Gws , KBws , ICws ,
  and ICws , 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
• 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 ? ltP, Agt, 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 lt 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 lt Td
• EXP2 E( eShop, alice, deliver( device ), Td )
  ? Td 50
• ? E( alice, eShop, pay( device, cc ), Tp ) ?
  Tp lt Td
• ? E( eShop, alice, give_guarantee, Tg ) ? Tg
  lt Tp

20
Verification in WAVe

• EXP2 E( eShop, alice, deliver( device ), Td )
  ? Td 50
• ? E( alice, eShop, pay( device, cc ), Tp ) ?
  Tp lt Td
• ? E( eShop, alice, give_guarantee, Tg ) ? Tg
  lt Tp
• HAP3 H( eShop, alice, give_guarantee, Tg ) ?
  Tg lt Tp
• HAP4 H( eShop, alice, give_guarantee, Tg ) ?
  Tg lt Tp
• ? H( alice, eShop, pay( device, cc ), Tp ) ?
  Tp lt Td
• HAP5 H( eShop, alice, give_guarantee, Tg ) ?
  Tg lt Tp
• ? H( alice, eShop, pay( device, cc ), Tp ) ?
  Tp lt Td
• ? H( eShop, alice, deliver( device ), Td ) ?
  Td lt 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 others capabilities,
  but by reasoning about policies exchanged at
  run-time?
• WAVe Architecture (layers RIF, KR, reasoning)
• Framework (ALPevents)
• Modeling (alice eShops policies, goals and KB)
• Semantics (based on AEDP A-minimal abductive
  answers achieving a goal)
• Verification (alices 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!