semantic web services in a transactional context prole 2013 ( madrid )

F R A N C I S C O J . G A L A N A N D A H M E D R I V E R A SU N I V E R S I T Y O F S E V I L L E

SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT

PROLE 2013 (MADRID)


CONTENT

1. Purpose2. Conceptualization3. Formalization4. Service matchmaking5. Conclusions


PURPOSE

To formalize a class of semantic web services (SWS) based on the concept of executional entailment. The formalization (1) integrates functional and procedural aspects, (2) facilitates the dynamic integration of SWSs with databases and (3) solves the problem of service matchmaking in an effective way.


CONCEPTUALIZATION

• State = set of properties which are true in the system under consideration.• Data invariant = set of constraints which must satisfy any possible

state in the life of a system.• Canonical state = prototypical state.


CONCEPTUALIZATION

• Service request = outputs or effects a web client want to achieve by executing a hypothetical service.• Semantic web service (SWS) = specification of a service by a set of

possible sequences of states. • Canonical execution = prototypical execution of a semantic web

service.


CONCEPTUALIZATION

• It is important to remark:

• By state, we mean an abstraction of a (real) state in the execution of a service.

• By execution of a SWS, we mean an abstraction of a (real) execution of a service.

• The execution of a SWS ≠ choreography (i.e. interaction with the client in order to consume the service).

• The execution of a SWS ≠ orchestration (i.e. interaction with other sevices in order to implement the functionality of the service).


CONCEPTUALIZATION. EXAMPLES

• Service request (generic) ://Buy a product in stock with delivery before invoicing Service request: buy(p,c) {Pre: product p is in stock } {Int1: product p is delivered to customer c }

{Post: product p is delivered to customer c and an invoice is issued }

Service requests (concrete): // Someone want to buy a PC with delivery before invoicing = buy(PC,c)// JN want to buy a PC with delivery before invoicing = buy(PC,JN)



• Semantic web service://Sell a product in stock to a customer with delivery before invoicingService: sell(p,c){Pre: product p is in stock }{Transaction: add customer c, deliver product p to customer c, issue an invoice and consider p as a sold product {Post: product p is sold to customer c, p is delivered to c and an invoice is issued to formalize the selling of p to c}



Data invariant:

// For every sold product must exist a customer, a delivery and an invoice.// Every product which has been delivered to a customer can not be in // stock.// Customers and products are disjoint sets of individuals.// …



State: PC is a product in stock (PC is a concrete individual).

Canonical State: p is a product in stock (p is a protoypical individual).



Execution:state 1: PC is a product in stock,TV is a product, RB is a customer. state 2: PC is a product in stock, TV is a product, JN is a customer, RB is a customer.state 3: PC is delivered to JN, TV is a product, RB is a customer.state 4: product PC is delivered to JN, an invoice is issued to JN in order to formalize the selling of PC, TV is a product, RB is a customer.



Canonical execution: state 1: p is a product in stock. state 2: p is a product in stock, c is a customer. state 3: p is a product in stock, c is a customer, p is delivered to c. state 4: p is a product in stock, c is a customer, p is delivered to c, an invoice is issued in order to formalize the selling of p to c.


FORMALISM

state: a set of ground atoms. e.g. state = { product(PC), stock(PC) }

canonical state: a set of atoms with labelled nulls, e.g. state = { product(p), stock(p) } being p a labelled null (protoypical individual).

A formula Y(X,Y) where is a conjunction of atoms can be translated to a canonical state by replacing each variable in Y(X,Y) by a labelled null.eg. canonical(s(supplies(s,p) product(p))) { supplies(s,p), product(p)}.


FORMALISM

Similarity between canonical state and state:Given a canonical state s1 and a (concrete) state s2, we say that s2 is similar to s1, s1 s2, iff there is a substitution such that s1 s2. e.g.: canonical state: s1 = { product(p), stock(p) }

state: s2 = { product(PC), stock(PC), product(TV), customer(RB) }

s1 s2 with = { p/PC }


FORMALISMData invariant: a (finite) set of formulas of the form X((X) Y(X,Y)) or X((X) false) inv1:

// For every sold product must exist a customer, a delivery and an invoice.p(product(p) sold(p) c(customer(c) delivery(p,c) invoice(p,c))// Every product which is delivered can not be in stock.p,c(product(p) delivery(p,c) stock(p) false)// Customers and products are disjoint sets of individuals.p,c(product(p) delivery(p,c) stock(p) false)


FORMALISMExecution: (finite) sequence of states satisfying an invariant. It is denoted as <state1, …, staten>inv

e.g. <s1,s2,s3,s4>inv1, beings1 = { product(PC), stock(PC), product(TV), customer(RB) }

s2 = { product(PC), stock(PC), customer(JN), product(TV), customer(RB) }

s3 = { product(PC), delivery(PC,JN), customer(JN), product(TV), customer(RB) }

s4 = { product(PC), delivery(PC,JN), customer(JN), invoice(PC,JN), sold(PC), product(TV), customer(RB) }

Notational conventions: <state1, …>inv denotes an execution which starts from state1.

<…,staten>inv denotes an execution which ends in staten.


FORMALISM

Canonical execution: execution composed of canonical states only.e.g.: <state1,state2,state3,state4>inv1, where

state1 = { product(p), stock(p) }

state2 = { product(p), stock(p), customer(c) }

state3 = {product(p), customer(c), delivery(p,c) }

state4 = {product(p), customer(c), delivery(p,c), invoice(p,c), sold(p) }


FORMALISMGiven a canonical execution e1 and an execution e2, we say that e2 is similar to e1, e1 e2, iff | e1 |=| e2 | and there is a substitution such that, for each si in e1 and ti in e2, si ti.

E.g. : e1 e2 with ={p/PC,c/JN} and being e2 : s1 = {product(PC), stock(PC), product(TV), customer(RB) }

s2 = { product(PC), stock(PC), customer(JN), product(TV), customer(RB) }

s3 = { product(PC), delivery(PC,JN), customer(JN), product(TV), customer(RB) }

s4 = { product(PC), delivery(PC,JN), customer(JN), invoice(PC,JN),

sold(PC), product(TV), customer(RB) } e1 : state1 = { product(p), stock(p) }

state2 = { product(p), stock(p), customer(c) }

state3 = {product(p), customer(c), delivery(p,c) }

state4 = {product(p), customer(c), delivery(p,c), invoice(p,c), sold(p) }


FORMALISM

Transaction: a set of formulas of the form: r(X)Y((X,Y)) where r is a relation symbol and a formula recursively written from the following elements: (a) primitive consult (consult), (b) primitive update (add, del), (c) (restricted) paralell conjunction (), (d) serial conjunction (), (e) (restricted) transaction invocation, (f) (restricted) existential quantification () and (h) negation ().

e.g. productInStock(p) consult(product(p))

sell2(p,c) productInStock(p) s(consult(provider(s)) (add(provision(p,s)) add(stock(p))) sell1(p,c))


FORMALISM

The semantics of a transaction is formalized by executional entailments of form <state1,… ,staten>inv |= .

<state>inv |= consult(r(C)) iff r(C) state.<state>inv |= consult(r(X)) iff there is C such that r(C) state.

r(C) state1 <state1,state2>inv |= del(r(C)) iff state2 = state1 – {r(C)}.

r(C) state <state>inv |= del(r(C))

r(C) state1 < state1, state2>inv |= add(r(C)) iff state2 = state1 {r(C)}.

r(C) state <state>inv |= add(r(C))


FORMALISM

<state1,… ,staten>inv |= X((X)) iff

<state1,… ,staten>inv |= (C) where C satisfies the safeness condition

(C is computed by a consult).

<state1,… ,staten>inv |= iff <state1,… ,staten>inv |


FORMALISM

Service request: sequence of formulas {Pre} {Int1}, …, {Intn} {Post} where each formula is of the form Y(X,Y), being is a conjunction of atoms.

e.g.//Buy a product in stock with delivery before invoincingService request: buy(p,c){Pre: product(p) stock(p)}{Int1: product(p) customer(c) delivery(p,c)}

{Post: product(p) customer(c) delivery(p,c) invoice(p,c)}


FORMALISM Service request: g {Pre} {Int1} … {IntJ}

{Post} SEM(g) = the canonical execution of g + all executions similar to the canonical one.

(the canonical execution of g) state1 = canonical(Pre), state2 = canonical(Int1), … stateJ+1= canonical(IntJ), stateJ+2 =canonical(Post)


FORMALISM

• Semantic web service: pre/post specification extended with a transaction of the form r 1, …, r n where precondition and postcondition are formulas of the form Y((X,Y)) and each i, with i=1..n, is a transactional formula.

• e.g.: //Sell a product in stock with delivery before invoincing• Service: sell1(p,c)

{Pre: product(p) and stock(p)}{Transaction: sell1(p,c) add(customer(c)) (add(delivery(p,c)) del(stock(p))) (add(invoice(p,c)) del(sold(p))){Post: product(p) sold(p) customer(c) delivery(p,c) invoice(p,c)}


FORMALISMService: r {Pre} {Transaction: r 1, …, r k}

{Post} SEM(r) = k canonical executions of r + all executions similar to some canonical execution of r such that

<state1,… ,staten>inv |= j, with j=1..k, such that

state1 |= Pre and staten |= Post


SERVICE MATCHMAKINGIt is the mechanism which maps appropriate SWSs to service requests.

We propose a matchmaking method based on two phases: (phase 1) prototypical matchmaking and (phase 2) concrete matchmaking.

The purpose of the prototypical matchmaking is to select those SWSs which may satisfy the service request. This selection is based on canonical executions.

The purpose of the concrete matchmaking is to select those SWSs which can satisfy the service request. This selection is based on (concrete) executions.

If every canonical state in a service request is included in an state of the canonical execution of the SWS then we can conclude that the SWS may satisfy the service request.


PROTOTYPICAL SERVICE MATCHMAKINGIn order to know which SWSs may satisfy a service request, we propose the construction of a matrix in order to compare the canonical execution of the service request with the canonical execution of the SWS.

As we can see, every canonical state in the service request is contaned in some state of the canonical execution of the SWS. Therefore, we can conclude that the SWS may satisfy the service request.

sellbuy

state1 state2 state3 state4 state5

state1

state2

state3


CONCRETE SERVICE MATCHMAKING

The second phase of the matchmaking focuses on the selection of those SWSs which can satisfy the service request.

A SWS can satisfy a service request if it can develop some execution similar to the canonical execution of the service request.

Problem: the construction of (concrete) executions are expensive because we have to access to the web for extracting the current state of the system.



We assume that the execution of a SWS does not affect the whole state of the system. Therefore, we propose to access to the web for extracting the affected substate only.

To check an invariant is usually an expensive task. A way to palliate this cost is by following a solution inspired by the RETE algorithm.

Due to the form of the rules in an invariant, we must only check those rules whose antecedents are satisfied in each state of the execution of the SWS. X((X) Y(X,Y)) or X((X) false)



Suppose that a client want to achieve the service request buy(PC,JN) and the prototypical matchmaking has selected buy(p,c) as a SWS which may satisfy it.We access to the web in order to extract the current state of the system but restricted to the substate affected by the execution of buy(PC,JN).

(scenario 1) state1 = { product(PC), customer(JN), delivery(PC,JN) }

The precondition of buy(PC,JN) is { product(PC), stock(PC) }As we can verify, state1 | Pre (conclusion: service matchmaking fails)


CONCRETE SERVICE MATCHMAKING(scenario 2) state1 = { product(PC), customer(JN), stock(PC) }

The execution of , the transaction in buy, can begin from state 1 because state1 |= PreLet < state1, state2, state3, state4 > be the execution of buy(PC,JN), being

state2 = { product(PC), stock(PC), customer(JN) }

state3 = { product(PC), delivery(PC,JN), customer(JN) }

state4 = { product(PC), delivery(PC,JN), customer(JN), invoice(PC,JN), sold(PC) }As we can verify, < state1, state2, state3, state4 > |= and state4 |= Post(conclusion: service matchmaking is successful)


CONCLUSIONS

We have proposed a formalism for specifying and executing semantic web services based on the concept of executional entailment.

The formalism has been designed having in mind three main requirements: (1) integration of functional and procedural aspects, (2) dynamic integration of SWSs with databases and (3) effective solution to the problem of service matchmaking.

F R A N C I S C O J . G A L A N A N D A H M E D R I V E R A SU N I V E R S I T Y O F S E V I L L E


PROLE 2013 (MADRID)

semantic web services in a transactional context prole 2013 ( madrid )

Documents

semantic web service

product p

examples semantic web

jn semantic web services

madridsemantic web services

web client

customer c

sold product