1. Ivan LaneseDepartment of Computer Science University of Bologna INRIA research team FOCUS Choreography-driven design Joint work with: Mario Bravetti, Gianluigi Zavattaro

2. Plan of the  From Choreography to Contracts  Contract-based Service Discovery  Conclusion Plan of the Talk

3. Different models for interacting systems  Choreography (e.g. WS-CDL): Top abstract view of the system, composed by communications involving two of its participants  Orchestration (e.g. WS-BPEL) Set of contracts describing the components of the system, composed by sendings & receivings of messages

4. WS-CDL  Global view of service interactions Buyer Seller Bank

5. WS-CDL  Global view of service interactions Buyer Seller Request Bank

6. WS-CDL  Global view of service interactions Buyer Seller PayDescr Request Offer Bank

7. WS-CDL  Global view of service interactions Buyer Seller PayDescr Request Offer Bank Payment

8. WS-CDL  Global view of service interactions Buyer Seller PayDescr Request Offer Bank Payment Confirm Receipt

9. WS-CDL Request Buyer  Seller ; (Offer Seller  Buyer | PayDescr Seller  Bank ) ; Payment Buyer  Bank ; (Confirm Bank  Seller | Receipt Bank  Buyer ) Explicit representation of concurrency

10. Projection of the Choreography on the Single Participants Buyer: Send(Request)@Seller;Receive(Offer); Send(Payment)@Bank;Receive(Receipt) Seller: Receive(Request); (Send(Offer)@Buyer | Send(PayDescr)@Bank); Receive(Confirm) Bank: Receive(PayDescr);Receive(Payment); (Send(Receipt)@Buyer | Send(Confirm)@Seller)

11. Well Formed WS-CDL Choreographies  Can we always project (in a simple way) a WS-CDL choreography by preserving its behavior?  Which kind of behavior is preserved?

12. A Formal Model for WS-CDL  A global choreography language: H ::=a r  s | 1 | 0 | H;H | H+H | H|H

13. A Formal Model for WS-CDL  A global choreography language: H ::=a r  s | 1 | 0 | H;H | H+H | H|H r invokes the operation a of s Successful termination Unsuccessful termination

14. A Formal Model for WS-CDL  A global choreography language: H ::=a r  s | 1 | 0 | H;H | H+H | H|H Choice Sequence Parallel

15. A Formal Model for orchestrations  A language for orchestrations: P ::=a | a r | 1 | 0 | P;P | P+P | P|P S ::= [P] r | S|S

16. A Formal Model for orchestrations  A language for orchestrations: P ::=a | a r | 1 | 0 | P;P | P+P | P|P S ::= [P] r | S|S receive on a Successful termination Unsuccessful termination invoke a at r

17. A Formal Model for orchestrations Choice Sequence Parallel  A language for orchestrations: P ::=a | a r | 1 | 0 | P;P | P+P | P|P S ::= [P] r | S|S

18. A Formal Model for orchestrations  A language for orchestrations: P ::=a | a r | 1 | 0 | P;P | P+P | P|P S ::= [P] r | S|S Behaviour of participant r Parallel composition of participants

19. The “canonical” projection  Projection [[ H ]] t of choreography H to participant t a s if t=r [[ a r  s ]] t =aif t=s 1otherwise [[H;H’]] t =[[H]] t ; [[H’]] t [[H|H’]] t =[[H]] t | [[H’]] t [[H+H’]] t =[[H]] t + [[H’]] t  Essentially an homomorphism

20. Example  Consider the global choreography: a r  s ; b t  u  Projection: [ a s ;1] r | [ a;1 ] s | [ 1;b u ] t | [ 1;b ] u  Are the two models equivalent? NO But, if r=t…. YES (synchronous) [ a s ; b u ] r | [ a;1 ] s | [ 1;b ] u

21. Asynchronous communication  Reconsider the example assuming asynchronous communication [ a s ; b u ] r | [ 1;a ] s | [ 1;b ] u  Communication on a starts before communication on b but could finish after  What we should observe? Send, receive, both, …?

22. A lattice of possible observation criteria SenderReceiver Sender-receiver Synchronous Disjoint

23. A lattice of possible observation criteria SenderReceiver Sender-receiver Synchronous Disjoint Assuming synchronous communication: observe either send or receive

24. A lattice of possible observation criteria SenderReceiver Sender-receiver Synchronous Disjoint Assuming asynchronous communication: observe send

25. A lattice of possible observation criteria SenderReceiver Sender-receiver Synchronous Disjoint Assuming asynchronous communication: observe receive

26. A lattice of possible observation criteria SenderReceiver Sender-receiver Synchronous Disjoint Assuming asynchronous communication: observe send and observe receive

27. A lattice of possible observation criteria SenderReceiver Sender-receiver Synchronous Disjoint Assuming asynchronous communication: observe send and receive together

28. What about the previous example?  Reconsider the example a r  s ; b r  u [ a s ; b u ] r | [ 1;a ] s | [ 1;b ] u  OK: for synchronous and sender  NO: for receiver, sender-receiver, disjoint

29. Main result  For each observation criterion: Sufficient syntactic conditions (connectedness, unique point of choice, and causality safety) that guarantee that a choreography is equivalent to its projection

30. Unique point of choice  In a choice H+H’ The sender of the initial transitions in H and in H’ is always the same The roles in H and in H’ are the same  Example: if we drop the second condition (a r  s + b r  t ); c s  t [ ( a s +b t );1] r | [ (a+1);c t ] s | [ (1+b);c ] t

31. Which equivalence between choreography and orchestration?  Synchronous equivalence: global transitions are matched by synchronous local transitions  Sender equivalence: global transitions are matched by local sends, local receives are abstracted away weak w.r.t. local receive transitions  Receiver equivalence: global transitions are matched by local receives, local sends are abstracted away weak w.r.t. local send transitions  Sender-Receiver equivalence: both conditions above  Disjoint equivalence: global transitions are matched by a pair of a local send and a local receive

32. Example: Receiver equivalence  Global choreography: a r  s ; b t  s  Local choreography: [ 1;a s ] r | [ a;b ] s | [ 1;b s ] t  The two systems are receiver equivalent

33. Amending choreographies  What can we do if a choreography does not satisfy the conditions? We can automatically transform it into one that satisfies the conditions for disjoint equivalence Preserving the “weak” traces  We add actions which are used only for synchronization and are not observed

34. Example: Amending choreographies  Original choreography: ( a r  s | c r  u ) ; b t  s  Amended choreography: ( a r  s ; h* s  z |c r  u ; i* u  z ) ;j* z  t ; b t  s  The two systems are now weak disjoint equivalent  Similar patterns for all the criteria

35. Which equivalence to choose?  Synchronous equivalence: if I have a synchronous system (easy )  Sender equivalence: ensures that data are available when needed  Receiver equivalence: ensures that invariants in the choreography hold in the projected system  Sender-Receiver equivalence: both the properties above  Disjoint equivalence: robust also in case of message loss

36. Example  Consider the global choreography: withdraw cust  bank ; pay cust  shop  Projection: [ w bank ;p shop ] cust | [ 1;w ] bank | [ 1;p ] shop  In the choregraphy money is never created  In the system I can pay before the bank has updated my account amount

37. Example  In a receiver connected choreography this will not happen withdraw cust  bank ; notify bank  shop ; pay cust  shop  Also in the projection the bank has updated the account before money can be spent

38. Plan of the  From Choreography to Contracts  Contract-based service discovery  Conclusion Plan of the Talk

39. Contracts  Contract: service “behavioural interface” correct sequence of invoke and receive just finite-state labeled transition system with successful termination Contract: abstract service description Service public registry

40. Contract Compliance  Verification of correctness of service composition based on their contracts: successful interaction i.e. no deadlock / termination reached Contract: abstract service description Service … Contract: abstract service description Service … public registry Reciprocal invocations

41. Service Compliance: Formally  Services are compliant if the following holds for their composition S : S --->* S’ implies that there exist S’’ and S’’’ s.t. S’ --->* S’’ ---> S’’’ i.e. every computation can be extended to reach successful completion of all services termination under fairness assumption τ √ τ

42. Example: compliant services  The following pairs of services are compliant: C 1 = a+b+cC 2 = a + b C 1 = a;bC 2 = a | b C 1 = (a; b )* C 2 = a;( b;a )*;b

43. … Choreography Compliance-Preserving Contract Refinement ! Contract public registry Contract public registry Service … Reciprocal invocations Contract Part. 1 Contract Part. n … refines compliance preserved by refinement compliant by construction projection

44. … Choreography Contract Refinement Relation Contract public registry Contract public registry Service … Reciprocal invocations Contract Part. 1 Contract Part. n … refines compliance preserved by refinement compliant by construction

45. Formally: Subcontract Preorder C sub-contracts of C subcontract preorder  Preorder ≤ between contracts C : C’ ≤ C means C’ is a subcontract of C

46. Definition of Preorder Induced from Independent Refinement C 1 C 2 C n Given a set of compliant contracts is a set of compliant contracts subcontract preorder sub-contracts of C 2 … sub-contracts of C 1 sub-contracts of C n C’ 1 C’ 2 C’ n … …

47. No maximal subcontract preorder … in general  Consider the system: [ a ] | [ a ] we could have one preorder ≤ 1 for which a + c.0 ≤ 1 a and one preorder ≤ 2 for which a + c.0 ≤ 2 a but no subcontract preorder could have a + c.0 ≤ a  Consequence: no independent refinement!

48. Maximal pre-order  It exists under some assumptions: Limiting the considered services (output persistence) Strengthening the notion of compliance (strong compliance) Moving to asynchronous communication (e.g. via message queues)

49. Output persistence  Output persistence means that given a process state P: If P has an output action on a and P-->P’ with  different from output on a, then also P’ has an output on a  This holds, for instance, in WS-BPEL (without faults) Pick operator is input guarded  Difficult to force if mixed choice is used 

50. Example  Given the choreography: Request Alice  Bob ; (Accept Bob  Alice + Reject Bob  Alice ) The following services can be retrieved: [τ;Request Bob ;(Accept+Reject)] Alice | [Request;(τ;Accept Alice +τ;Reject Alice )] Bob

51. Example  Given the choreography: Request Alice  Bob ; (Accept Bob  Alice + Reject Bob  Alice ) The following services can be retrieved: [τ;Request Bob ;(Accept+Reject)] Alice | [Request;(τ;Accept Alice +τ;Reject Alice )] Bob [τ;Request Bob ;(Accept+Reject+Retry)] Alice | [Request;(τ;Accept Alice +τ;Reject Alice )] Bob

52. Example  Given the choreography: Request Alice  Bob ; (Accept Bob  Alice + Reject Bob  Alice ) The following services can be retrieved: [τ;Request Bob ;(Accept+Reject)] Alice | [Request;(τ;Accept Alice +τ;Reject Alice )] Bob [τ;Request Bob ;(Accept+Reject+Retry)] Alice | [Request;(τ;Accept Alice +τ;Reject Alice )] Bob [τ;Request Bob ;(Accept+Reject+Retry)] Alice | [Request;τ;Accept Alice ] Bob

53. “Standard” Contract Compliance  Example: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3

54. “Standard” Contract Compliance  Example: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3

55. “Standard” Contract Compliance  Example: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3

56. “Standard” Contract Compliance  Example: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3

57.  Let us give a more careful look: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3 Alternatives to Standard Compliance: Strong Compliance

58.  Let us give a more careful look: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3

59.  Let us give a more careful look: S 1 : invoke(a);invoke(b) S 2 : receive(a);invoke(c) S 3 : receive(c);receive(b) S1S1 S2S2 S3S3  Strong compliance requires that the receptors should be always ready  These services are not strongly compliant !! Alternatives to Standard Compliance: Strong Compliance

60. Example: strong compliant services  The following pairs of services are strong compliant: C 1 = a+b+cC 2 = a + b C 1 = a;bC 2 = a | b C 1 = (a; b )* C 2 = a;( b;a )*;b

61. Example: strong compliant services  The following pairs of services are strong compliant: C 1 = a+b+cC 2 = a + b C 1 = a;bC 2 = a | b C 1 = (a; b )* C 2 = a;( b;a )*;b

62. “Strong” refinement  It allows also refinement on names already in the interface: Receive(a);(Receive(b)+Receive(a)) ≤ Receive(a);Receive(b)

63. Summary of Results  “Normal” compliance: Unconstrained contracts: maximal relation does not exist Contracts satisfying output persistence: maximal relation exists if output alphabet of contracts is known Contracts satisfying output persistence where outputs are directed to a location: maximal relation exists  Strong compliance: Unconstrained contracts (where output are directed to a location): maximal relation exists  Queue-based compliance: Unconstrained contracts (where output are directed to a location): maximal relation exists

64. Summary of Results  Direct conformance w.r.t. the whole choreography: maximal relation does not exist (all kinds of compl.)  Sound characterizations of the relations obtained (apart from the queue based) by resorting to an encoding into (a fair version of) must testing [RV05] With respect to testing: both system and test must succeed  As a consequence: Algorithm that guarantees compliance Classification of the relations w.r.t. existing pre-orders: coarser than (fair) must testing (e.g., they allow external non-determinism on inputs to be added in refinements)

65. Plan of the  From Choreography to Contracts  Contract-based service discovery  Conclusion Plan of the Talk

66. Future work  Choreographies with dynamic participant creation  Contracts with operators for process interruption and compensation The contract language becomes partially undecidable

67. Related work  Carbone, Honda, Yoshida Global and End-point calculus similar to our choreography and orchestration Only some of our observation criteria are considered Stronger conditions for projection

68. Related work  Fu, Bultan, Su Service systems with message queues similar to ours Observe the send event as in our sender observation criterion No refinement

69. Related work  Padovani et al. Contracts described with an ad-hoc transition system (reminiscent of acceptance tree) The absence of maximal subcontract relation solved either with explicit interfaces or filters (cut the additional actions of the refinements)

70. Related work  van der Aalst et al. Contracts described with open workflow nets (similar to petri nets) Same notion of compliance Same definition of subcontract as maximal refinement that preserves compliance Characterization of the refinement for processes without “loops” (make the system infinite due to message queues)

71. References  M. Bravetti and G. Zavattaro. Contract based Multi-party Service Composition. In FSEN’07. (full version in Fundamenta Informaticae)  M. Bravetti and G. Zavattaro. Towards a Unifying Theory for Choreography Conformance and Contract Compliance. In SC’07.  M. Bravetti and G. Zavattaro. A Theory for Strong Service Compliance. In Coordination’07. (full version in MSCS)  M. Bravetti and G. Zavattaro. Contract Compliance and Choreography Conformance in the presence of Message Queues.In WS-FM’08  M. Bravetti and G. Zavattaro. On the Expressive Power of Process Interruption and Compensation. In WS-FM’08  I. Lanese, C. Guidi, F. Montesi, and G. Zavattaro. Bridging the Gap Between Interaction- and Process-oriented Choreographies. In SEFM’08.  M. Bravetti, I. Lanese, G. Zavattaro. Contract-Driven Implementation of Choreographies.In TGC'08  M. Bravetti, G. Zavattaro. Contract-Based Discovery and Composition of Web Services. In Formal Methods for Web Services, Advanced Lectures, LNCS 5569  M. Boreale, M. Bravetti. Advanced Mechanisms for Service Composition, Query and Discovery in Rigorous Software Eng. for Service-Oriented Systems, LNCS, to appear