policy based reasoning for smart web service interaction n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Policy-based reasoning for smart web service interaction PowerPoint Presentation
Download Presentation
Policy-based reasoning for smart web service interaction

Loading in 2 Seconds...

play fullscreen
1 / 22

Policy-based reasoning for smart web service interaction - PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on

Policy-based reasoning for smart web service interaction. Federico Chesani, Paola Mello, Marco Montali, Paolo Torroni Marco Alberti, Marco Gavanelli, Evelina Lamma. MOTIVATION. Service Oriented Computing off-the-shelf solutions (web services) composition of w.s. into new applications

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Policy-based reasoning for smart web service interaction' - mare


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
policy based reasoning for smart web service interaction

Policy-based reasoning for smart web service interaction

Federico Chesani, Paola Mello, Marco Montali, Paolo Torroni

Marco Alberti, Marco Gavanelli, Evelina Lamma

motivation
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
focus
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

example alice eshop
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.”

example alice eshop cont d
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
example alice eshop cont d1
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

wav e framework
WAVeFramework
  • Enables reasoning about possible events
  • Separates private knowledge(Gws & KBws) from public knowledge (policies/ICws )
wav e framework1
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)
modelling in wav e g ws
Modelling in WAVeGws
  • Sample alice goal: “to have device at time 50.”

have( alice, device, 50 ) .

modelling in wav e kb ws
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.

modelling in wav e ic ws 1
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 .

modelling in wav e ic ws 2
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 ).

semantics of wav e abductive answer hap exp

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’

semantics of wav e entailment
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

semantics of wav e a minimality
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 }

semantics of wav e possible interactions
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)
verification in wav e
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] }

verification in wav e1
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 }

verification in wav e2

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 ) }

conclusion
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)
other work
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!