ALMA MATER STUDIORUMUNIVERSITY OF BOLOGNA UNIVERSITY OF FERRARA

Policy-based reasoning for Policy-based reasoning for smart web service interactionsmart web service interaction

Federico Chesani, Paola Mello, Marco Montali, Paolo Torroni

Marco Alberti, Marco Gavanelli, Evelina Lamma

2

MOTIVATION

Service Oriented ComputingService Oriented Computing off-the-shelf solutions (web services)off-the-shelf solutions (web services) composition of w.s. into new applicationscomposition of w.s. into new applications

Many advantagesMany advantages rapid prototypingrapid prototyping complex applications from simple elementscomplex applications from simple elements

Some problemsSome problems decreasing lifetime of softwaredecreasing lifetime of software need to cope with proliferation of new need to cope with proliferation of new

servicesservices difficult to remain competitivedifficult 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?

WAVWAVee Architecture Architecture FrameworkFramework ModelingModeling SemanticsSemantics VerificationVerification

Exam

ple

Exam

ple

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: 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

Example:alice & eShop (cont’d)

Reasoning about policies: possible steps1. alice requests from eShop its policies

regarding the sales of device2. 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

WA

VW

AV

ee

7

WAVe Architecture

WAVe Framework

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: <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 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 WAVe

ICws (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 WAVe

ICws (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

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 thatKBws HAP EXP ⊨ Gws

KBws HAP EXP ⊨ ICws ICws’ abductive answerabductive answer

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-minimality1Sakama & 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

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

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

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?

WAVWAVee Architecture Architecture (layers: RIF, KR, (layers: RIF, KR, reasoning)reasoning)

Framework Framework (ALP+events)(ALP+events) Modeling Modeling ((alice alice & & eShopeShop’s policies, goals ’s policies, goals

and KB)and KB) Semantics Semantics (based on AEDP: A-minimal (based on AEDP: A-minimal

abductive answers achieving a goal)abductive answers achieving a goal) Verification Verification ((alicealice’s achievable goal)’s achievable goal)

22

OTHER WORK

Related WorkRelated Work Huge literature on architectures, logics, and Huge literature on architectures, logics, and

languages for the semantic web languages for the semantic web Work on policies, e.g. Bradshaw et al. and Work on policies, e.g. Bradshaw et al. and

Finin et al.Finin et al. Work on agent protocols, e.g. Singh et al. and Work on agent protocols, e.g. Singh et al. and

SCIFFSCIFF Proof-procedures and semantics for ALPProof-procedures and semantics for ALP

Future WorkFuture Work Extensive empirical evaluation of WAVExtensive empirical evaluation of WAVee Selection/filtering of policies (Selection/filtering of policies (point 2.)) Use of the output of WAVUse of the output of WAVee by web services ( by web services (

point 4.)) Exchange of policies between web servicesExchange of policies between web services

thanks for your attention!