1. FRANCISCO J. GALAN AND AHMED RIVERAS UNIVERSITY OF SEVILLE SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT PROLE 2013 (MADRID)

2. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT CONTENT 1. Purpose 2. Conceptualization 3. Formalization 4. Service matchmaking 5. Conclusions

3. 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.

4. 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.

5. 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.

6. 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).

7. 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 } { Int 1 : 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)

8. 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}

9. 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. // …

10. 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).

11. 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.

12. 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.

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

14. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM Similarity between canonical state and state: Given a canonical state s 1 and a (concrete) state s 2, we say that s 2 is similar to s 1, s 1   s 2, iff there is a substitution  such that s 1   s 2. e.g.: canonical state: s 1 = { product(p), stock(p) } state: s 2 = { product(PC), stock(PC), product(TV), customer(RB) } s 1   s 2 with  = { p/PC }

15. 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) inv 1 : // 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)

16. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM Execution : (finite) sequence of states satisfying an invariant. It is denoted as inv e.g. inv1, being s 1 = { product(PC), stock(PC), product(TV), customer(RB) } s 2 = { product(PC), stock(PC), customer(JN), product(TV), customer(RB) } s 3 = { product(PC), delivery(PC,JN), customer(JN), product(TV), customer(RB) } s 4 = { product(PC), delivery(PC,JN), customer(JN), invoice(PC,JN), sold(PC), product(TV), customer(RB) } Notational conventions : inv denotes an execution which starts from state 1. inv denotes an execution which ends in state n.

17. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM Canonical execution : execution composed of canonical states only. e.g.: inv1, where state 1 = { product(p), stock(p) } state 2 = { product(p), stock(p), customer(c) } state 3 = {product(p), customer(c), delivery(p,c) } state 4 = {product(p), customer(c), delivery(p,c), invoice(p,c), sold(p) }

18. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM Given a canonical execution e 1 and an execution e 2, we say that e 2 is similar to e 1, e 1   e 2, iff | e 1 |=| e 2 | and there is a substitution  such that, for each s i in e 1 and t i in e 2, s i   t i. E.g. : e 1   e 2 with  ={p/PC,c/JN} and being e 2 : s 1 = {product(PC), stock(PC), product(TV), customer(RB) } s 2 = { product(PC), stock(PC), customer(JN), product(TV), customer(RB) } s 3 = { product(PC), delivery(PC,JN), customer(JN), product(TV), customer(RB) } s 4 = { product(PC), delivery(PC,JN), customer(JN), invoice(PC,JN), sold(PC), product(TV), customer(RB) } e 1 : state 1 = { product(p), stock(p) } state 2 = { product(p), stock(p), customer(c) } state 3 = {product(p), customer(c), delivery(p,c) } state 4 = {product(p), customer(c), delivery(p,c), invoice(p,c), sold(p) }

19. 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))

20. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM The semantics of a transaction is formalized by executional entailments of form inv |= . inv |= consult(r(C)) iff r(C)  state. inv |= consult(  r(X)) iff there is C such that r(C)  state. r(C)  state 1  inv |= del(r(C)) iff state 2 = state 1 – {r(C)}. r(C)  state  inv |= del(r(C)) r(C)  state 1  inv |= add(r(C)) iff state 2 = state 1  {r(C)}. r(C)  state  inv |= add(r(C))

21. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM inv |=  1  …   n iff inv |=  1 and inv |=  2  …   n inv |=  1  …   n iff for every serial conjunction of  1,…,  n, , we have that inv |=  and inv |=  inv |= r(C) iff r(X)  Y(  (X,Y)) and inv |=  Y(  (C,Y))

22. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM inv |=  X(  (X)) iff inv |=  (C) where C satisfies the safeness condition (C is computed by a consult). inv |=  iff inv |  

23. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM Service request: sequence of formulas { Pre } { Int 1 }, …, { Int n } { Post } w here 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)} { Int 1 : product(p)  customer(c)  delivery(p,c)} { Post : product(p)  customer(c)  delivery(p,c)  invoice(p,c)}

24. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT FORMALISM Service request : g { Pre } { Int 1 } … { Int J } { Post } SEM(g) = the canonical execution of g + all executions similar to the canonical one. (the canonical execution of g) state 1 = canonical( Pre), state 2 = canonical( Int 1 ), … state J+1 = canonical( Int J ), state J+2 =canonical( Post )

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

26. 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 inv |=  j, with j=1..k, such that state 1 |= Pre and state n |= Post

27. 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. 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.

28. 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. 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. sell buy state 1 state 2 state 3 state 4 state 5 state 1  state 2  state 3 

29. 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.

30. 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)

31. 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) state 1 = { product(PC), customer(JN), delivery(PC,JN) } The precondition of buy(PC,JN) is { product(PC), stock(PC) } As we can verify, state 1 |  Pre (conclusion: service matchmaking fails )

32. SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT CONCRETE SERVICE MATCHMAKING (scenario 2) state 1 = { product(PC), customer(JN), stock(PC) } The execution of , the transaction in buy, can begin from state 1 because state 1 |= Pre Let be the execution of buy(PC,JN), being state 2 = { product(PC), stock(PC), customer(JN) } state 3 = { product(PC), delivery(PC,JN), customer(JN) } state 4 = { product(PC), delivery(PC,JN), customer(JN), invoice(PC,JN), sold(PC) } As we can verify, |=  and state 4 |= Post (conclusion: service matchmaking is successful )

33. 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.

34. FRANCISCO J. GALAN AND AHMED RIVERAS UNIVERSITY OF SEVILLE SEMANTIC WEB SERVICES IN A TRANSACTIONAL CONTEXT PROLE 2013 (MADRID)