Download state

SEMANTIC WEB SERVICES IN A
TRANSACTIONAL CONTEXT
PROLE 2013 (MADRID)
FRANCISCO J. GALAN AND AHMED RIVERAS
UNIVERSITY OF SEVILLE
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONTENT
1. Purpose
2. Conceptualization
3. Formalization
4. Service matchmaking
5. Conclusions
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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).
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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 SERVICES IN A TRANSACTIONAL
CONTEXT
CONCEPTUALIZATION. EXAMPLES
• Semantic web service:
//Sell a product in stock to a customer with delivery before invoicing
Service: 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}
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONCEPTUALIZATION. EXAMPLES
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.
// …
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONCEPTUALIZATION. EXAMPLES
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).
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONCEPTUALIZATION. EXAMPLES
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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONCEPTUALIZATION. EXAMPLES
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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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)}.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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 }
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
FORMALISM
Data 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)
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
FORMALISM
Execution: (finite) sequence of states satisfying an invariant. It is denoted as
<state1, …, staten>inv
e.g. <s1,s2,s3,s4>inv1, being
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) }
Notational conventions:
<state1, …>inv denotes an execution which starts from state1.
<…,staten>inv denotes an execution which ends in staten.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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) }
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
FORMALISM
Given 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) }
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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))
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
FORMALISM
The semantics of a transaction is formalized by executional entailments of
form <state1,… ,staten>inv |= .
<state>inv |= consult(r(C))
<state>inv |= consult(r(X))
iff
iff
r(C)  state.
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))
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
FORMALISM
<state1,… ,staten+1>inv |= 1  …  n iff
< state1, state2 >inv |= 1 and < state2,…, staten+1 >inv |= 2  …  n
<state1,staten+1>inv |= 1  …  n iff
for every serial conjunction of 1,…, n, , we have that
< state1,…>inv |=  and <…, staten+1>inv |= 
<state1,… ,staten>inv |= r(C)
iff r(X)Y((X,Y)) and
<state1,… ,staten>inv |= Y((C,Y))
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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 | 
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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 invoincing
Service 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)}
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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)
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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)}
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
FORMALISM
Service: 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
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
SERVICE MATCHMAKING
It 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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
PROTOTYPICAL SERVICE MATCHMAKING
In 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.
sell
buy
state1
state2
state3
state1
state2
state3


state4
state5



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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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.
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONCRETE SERVICE MATCHMAKING
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)
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
CONCRETE SERVICE MATCHMAKING
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)
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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 |= Pre
Let < 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)
SEMANTIC WEB SERVICES IN A TRANSACTIONAL
CONTEXT
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.
SEMANTIC WEB SERVICES IN A
TRANSACTIONAL CONTEXT
PROLE 2013 (MADRID)
FRANCISCO J. GALAN AND AHMED RIVERAS
UNIVERSITY OF SEVILLE