1. Automated Composition and Analysis

2. Web Services: Design and Analysis2 Automated Composition Given a specification of the composite service, find individual services and their integration, or design the individual services Workflow Specified as tree or pre- and post-conditions Distributed system synthesis Web services: Activity based FSA Conversation protocols Golog

3. Web Services: Design and Analysis3 Composition in Roman Model Deterministic FSA with activities Composition? = product machine Composed service can be represented by FSA p1p1 p2p2 b r a r

4. Web Services: Design and Analysis4 Automated Composition in Roman Model Given : a set of FSAs C — existing services a single FSA M — desired service Can we compose M from C ? All machines start from initial states Each move in M is mapped to a move in one or more machines in C All machines end in final states b r a r a r b MC1C1 C2C2

5. Web Services: Design and Analysis5 Delegator Given M and C, a delegator is a mapping D such that for each word w accepted by M, D ( w ) is “accepted” by C b r a r a r b a r a r b r a r C 1 C 1 C 1 C 1 C 2 C 2 C 1 C 1 M C1C1 C2C2

6. Web Services: Design and Analysis6 Delegators and Mealy Machines A delegator for M b r a r a r b M C1C1 C2C2 a : C 1 b : C 2 r : C 2 r : C 1

7. Web Services: Design and Analysis7 Another Example Can we still delegate? t c t s t s t c Delegator: t s t c s t c M C3C3 C4C4 If tc then t : C 3 s : C 4 c : C 3 If ts then t : C 4  : C 4  : C 3 t :t : c : C 3 s : C 4

8. Web Services: Design and Analysis8 Composition FSA Given a set of FSAs C   C n, we construct the composition FSA Comp ( C   C n ) An FSA M can be composed from C if and only if L ( M )  L ( Comp ( C   C n ))

9. Web Services: Design and Analysis9 Constructing the Product Machine States are tuples of form  p 1  p 2  …  p n  p i are states of C i Transitions are assumed delegations Activity a is delegated to S For each C i in S :  i  p i  a  q i For each C i not in S : p i  q i p 1, p 2, …, p n q 1, q 2, …, q n a : S

10. Web Services: Design and Analysis10 Example of Composition FSA C1C1 C2C2 b r   a r       a r b M

11. Web Services: Design and Analysis11 Another Example of Composition FSA t   s t   c s t c M C3C3 C4C4    

12. Web Services: Design and Analysis12 Conversation Realizability Target conversations: a k shuff  o 1  shuff  r 1  b 1 p 1    o 2  shuff  r 2  b 2 p 2    Are there Mealy peers whose conversation language is exactly as specified? a uthorize ware- house1 okok b ill 2 p ayment 2 o rder 1 r eceipt 1 o rder 2 r eceipt 2 p ayment 1 b ill 1 bank ware- house2 store

13. Web Services: Design and Analysis13 Not Every Regular Language is Realizable ac Very simple language  abcde  When can a regular language be realizable? Sufficient conditions p1p1 b d p3p3 p4p4 e p2p2

14. Web Services: Design and Analysis14 A Sufficient Condition L is a regular language of a Mealy machine A A   A n are projections of A to peer , …, peer n whose corresponding languages are L   L n Part 1: Lossless join JOIN    L   n  L n  L ac p1p1 b d p3p3 p4p4 e p2p2

15. Web Services: Design and Analysis15 A Sufficient Condition: Part 2 L is a regular language of a Mealy machine A A   A n are projections of A to peer , …, peer n whose corresponding languages are L   L n Queues are optional: construct a product machine from determined versions of A   A n in which every message sent is ready to be read immediately ac p1p1 b d p3p3 p4p4 e p2p2 a b b c c d e

16. Web Services: Design and Analysis16 A Sufficient Condition: Part 3 L is a regular language of a Mealy machine A A   A n are projections of A to peer , …, peer n whose corresponding languages are L   L n A i ’s are autonomous: can only do only sends, only receive, or terminate papa pbpb pcpc c a b a b c b a

17. Web Services: Design and Analysis17 Analyzing Web Services Particularly important: Dynamic composition Hard to test/debug Service oriented development is more prone to bugs(?) Types of properties: Execution (deadlock, live lock) Conditions related to the world

18. Web Services: Design and Analysis18 From BPEL to FSA BPEL control structure can be translated into FSAs

19. Web Services: Design and Analysis19 Each atomic BPEL activity  an automaton single entry, single exit BPEL to Automata   [request/accept := “yes”] ? ? approve_Out   [request := approve_Out]

20. Web Services: Design and Analysis20 Each atomic BPEL activity  an automaton single entry, single exit, and may have several exception exits BPEL to Automata <invoke operation=“approve”, invar="request“, outvar=“aprvInfo” > handler1 ! ! approve_In ? ? approve_Out ? ? loanfault loanfaul t  [approve_In := request] [aprvInfo := approve_Out]

21. Web Services: Design and Analysis21 BPEL to Automata act1act2  fault2 fault1 Control flow constructs: assembling automata

22. Web Services: Design and Analysis22 act1   [b_link1 := cond1 ] act2   [b_link1] product BPEL to Automata

23. Web Services: Design and Analysis23 Linear Temporal Logic ( LTL ) A set of atomic propositions: p, q, r, … Logical connectives: , ,  Temporal operators: X G U F X  :  is true in the next state G  :  is true in every state  U  :  is true in every state before the state  is true F  :  is true in some future state G ( order  F ( Cancel  Receipt )) G ( Payment.amount = a  X ( Receipt.ammount=a ))

24. Web Services: Design and Analysis24 Semantics of LTL A state is a set of propositions A sequence of states w  w  w  w  … satisfies an LTL formula: w  p if w   p or p  w  w   if w     w   if w    and w     w  X  if w  w  …   w  G  if for each i, w i w i  …   w  F  if for some i, w i w i  …   w   U  if for some i, w i w i  …   and for each j < i, w j w j  … 

25. Web Services: Design and Analysis25 Guarantee no collisions Guarantee eventual service E S N Example: Traffic Light Controller

26. Web Services: Design and Analysis26 Module main(N_SENSE, S_SENSE, E_SENSE, N_GO, S_GO, E_GO); input N_SENSE, S_SENSE, E_SENSE; output N_GO, S_GO, E_GO; reg NS_LOCK, EW_LOCK, N_REQ, S_REQ, E_REQ; /* set request bits when sense is high */ always begin if (!N_REQ & N_SENSE) N_REQ = 1; end always begin if (!S_REQ & S_SENSE) S_REQ = 1; end always begin if (!E_REQ & E_SENSE) E_REQ = 1; end Controller Program

27. Web Services: Design and Analysis27 Controller for North Light always begin if (N_REQ) begin wait (!EW_LOCK); NS_LOCK = 1; N_GO = 1; wait (!N_SENSE); if (!S_GO) NS_LOCK = 0; N_GO = 0; N_REQ = 0; end South light is similar

28. Web Services: Design and Analysis28 always begin if (E_REQ) begin EW_LOCK = 1; wait (!NS_LOCK); E_GO = 1; wait (!E_SENSE); EW_LOCK = 0; E_GO = 0; E_REQ = 0; end Controller for East Light

29. Web Services: Design and Analysis29 Safety (no collisions) G  (E_GO  (N_GO  S_GO)) Liveness G (  N_GO  N_SENSE  F N_GO) G (  S_GO  S_SENSE  F S_GO) G (  E_GO  E_SENSE  F E_GO) Fairness constraints GF  (N_GO  N_SENSE) GF  (S_GO  S_SENSE) GF  (E_GO  E_SENSE) Specifications in LTL

30. Web Services: Design and Analysis30 East and North lights on at same time... E_Go E_Sense NS_Lock N_Go N_Req N_Sense S_Go S_Req S_Sense E_Req Counterexample

31. Web Services: Design and Analysis31 input: temporal logic spec finite-state model output yes no + counterexample MC G( p  F q ) yes no p q p q Model Checking (Clarke and Emerson)

32. Web Services: Design and Analysis32 Verifying Web Service Properties Finite state modeling checking: Approximate FSA states with propositions Approximate values in finite domain with propositions Approximate queues by finite length queues (i.e., FSAs)

33. Web Services: Design and Analysis33 Automata  Promela Translate to Promela (input lang. of SPIN) 1 web service composition  1 Promela specification 1 Guarded Automaton  1 Promela Process Each Promela process has one Channel Channel are bounded! Challenge: handling XML Data [ISSTA ’ 04] (bounded) XML Schema Type  Type system in Promela Symbolic emulation of XPath expression Special handling of position() and last() functions  Map each function to an integer variable

34. Web Services: Design and Analysis34 Handling of XPath helps find intricate bugs! Stock Analysis Service [ISSTA ’ 04] Experience with other examples Exhaustive search takes a lot of time Performance satisfactory when finding errors SPIN does not scale well with data domains Use of Symbolic Verification may help Verification Experience InvestorBroker Research Dept. regList of stockIDs 1 stockID per request Find stockID in last Request; If last ID in regList exit; Else send its subsequent stockID;

35. Web Services: Design and Analysis35 Front End Guarded Automata BPEL2GA Back End Sync. Analysis Complete verification Partial verification SPIN Guarded Automata allows flexible architecture WS-CHOREGRAPHY, OWL-S Symbolic Verification Interacting BPEL Web Services LTL Goals Web Service Analysis Tool ( WSAT )

36. Web Services: Design and Analysis36 OWL-S to Petri-Net OWL-S atomic processes: Pre- and post-conditions Each atomic process is translated to a Petri Net:

37. Web Services: Design and Analysis37 OWL-S to Petri Net Control structures “glue” pieces together

38. Web Services: Design and Analysis38 Choice

39. Web Services: Design and Analysis39 If-Then-Else

40. Web Services: Design and Analysis40 Loops

41. Web Services: Design and Analysis41 Petri Net based Verification Reachability Safety: “unsafe” states are not reachable Deadlock Results: DAML-S (0.5) is 1-safe (each place is marked 1 or less) Reachability is PSPACE-complete