1. Bridging the gap between Interaction- and Process-Oriented Choreographies Talk by Ivan Lanese Joint work with Claudio Guidi, Fabrizio Montesi and Gianluigi Zavattaro University of Bologna, Bologna, Italy

2. Roadmap  IOC and POC: two approaches to choreography  What does a IOC means?  Conditions for a correct projection  Behavioral correspondence  Conclusions 2

3. Roadmap  IOC and POC: two approaches to choreography  What does a IOC means?  Conditions for a correct projection  Behavioral correspondence  Conclusions 3

4. Service Oriented Computing  A paradigm for programming distributed applications by combining services  Dynamically retrieved from the net  Loosely coupled  From different organizations  Allows for great dynamicity and reusability  Based on international standards  WSDL for describing service interfaces  UDDI for describing service repositories  BPEL for combining services  … 4

5. Service choreography  A SOC application is usually composed by many services  At runtime services interact via complex multiparty conversations  A service choreography is the description of the possible conversation patterns  Fundamental to describe the behavior of SOC applications 5

6. Safari example 6 hire req. access grant confirm ask payment pay notify

7. IOC vs POC  There are two different approaches to choreography  Interaction-Oriented Choreography (IOC)  describes the conversation from a global point of view  composes basic interactions of the form  a sends a message to b on operation o  WS-CDL  Process-Oriented Choreography (POC)  obtained as composition of the behavior of different participants (roles)  describes the communication behaviour of each of them, e.g.  a performs an output on o 1, followed by an input on o 2  BPEL4CHOR 7 a o ¡ ! b ( o 1 ;o 2 ) a

8. From design to implementation  IOCs are more easy to understand and to write  Good tool for design  POCs are more easily implementable (in a distributed setting)  We want to translate automatically a IOC into a POC implementing it  We derive the POC behavior of each role via a projection  The POC is the composition of the projections on the different roles 8

9. IOC syntax basic interaction empty IOC terminated IOC sequential composition parallel composition nondeterministic choice 9 I :: = a o ¡ ! b j 1 j 0 j I 1 ; I 2 j I 1 k I 2 j I 1 + I 2

10. Idea of IOC semantics  Semantics based on LTS  Labels corresponding to basic interactions and termination 10 a o ¡ ! b p a o 1 ¡ ! b ; b o 2 ¡ ! c a o 1 ¡ ! b ¡¡¡¡ ! 1 ; b o 2 ¡ ! c b o 2 ¡ ! c ¡¡¡¡ ! 1 p ¡ ! 0

11. POC syntax role parallel composition output input empty POC terminated POC sequential composition parallel composition nondeterministic choice 11 S :: = ( P ) a j S 1 k S 2 P :: = o j o j 1 j 0 j P 1 ; P 2 j P 1 j P 2 j P 1 + P 2

12. Idea of POC semantics  Semantics based on LTS  Two possible semantics  Synchronous: output and input interact directly  Labels corresponding to interaction and termination  Asynchronous: the output spawns a message that is catched by the input  Labels corresponding to message spawning, interaction. and termination 12 a o ¡ ! b p o:a a o ¡ ! b p ( o ) a k( o ) b o:a ¡¡ ! ( 1 jh o i) a k( o ) b a o ¡ ! b ¡¡¡ ! ( 1 j 1 ) a k( 1 ) b p ¡ ! ( 0 ) a k( 0 ) b

13. Roadmap  IOC and POC: two approaches to choreography  What does a IOC means?  Conditions for a correct projection  Behavioral correspondence  Conclusions 13

14. Back to our aim  We want to project a given IOC onto roles to get a POC exhibiting the corresponding behavior  The projection is an homomorphism but for:  We look for conditions ensuring that such a projection behaves well 14 pro j ( a o ¡ ! b ; a ) = o pro j ( a o ¡ ! b ; c ) = 1 pro j ( a o ¡ ! b ; b ) = o

15. 15

16. What ; means?  Consider the simple IOC  In the synchronous case the (atomic) interaction between a and b should occur before the (atomic) interaction between c and d  In the asynchronous case there are different alternatives:  Sender: the sending at a should occur before the sending at c  Receive: the receive at b should occur before the receive at d  Sender-receive: both of the above  Disjoint: both the sending at a and the receive at b should occur before both the sending at c and the receive at d 16 a o 1 ¡ ! b ; c o 2 ¡ ! d

17. A partial order 17 Stricter constraints on IOC Stronger relation on behaviors Disjoint SenderReceiver Sender - receiver Synchronous

18. Roadmap  IOC and POC: two approaches to choreography  What does a IOC means?  Conditions for a correct projection  Behavioral correspondence  Conclusions 18

19. Conditions for a correct projection  We want conditions ensuring that the projection behaves well  They will depend on the chosen semantics  We have three kinds of “connectedness” conditions  For sequential composition  For choice  For operations used more than once  (No condition for parallel composition) 19

20. Connectedness for sequence  Ensures the correctness of sequential composition  Synchronous: {a,b} ∩ {c,d} ≠ Ø  Sender: a=c or b=c  Receiver: b=c or b=d  Disjoint: b=c  The conditions can be generalized to ensure the connectedness of 20 a o 1 ¡ ! b ; c o 2 ¡ ! d I ; J

21. Example  Consider:  The projection is:  The POC behaves well for synchronous and sender semantics  The POC is not connected for receiver or disjoint semantics 21 a o 1 ¡ ! b ; a o 2 ¡ ! d ( o 1 ;o 2 ) a k( o 1 ) b k( o 2 ) d

22. Points of choice  Ensures the correctness of choice  Synchronous:  The same role should occur in each initial transition  The roles in the two branches should be the same  Asynchronous:  The sender should be the same  The roles in the two branches should be the same 22 I + J

23. Points of choice: example  If we drop the condition on roles:  In the projection  Interaction on O 3 is enabled 23 ( a o 1 ¡ ! b + a o 2 ¡ ! c ) ; b o 3 ¡ ! c (( o 1 + o 2 ) ; 1 ) a k(( o 1 + 1 ) ;o 3 ) b k(( 1 + o 2 ) ;o 3 ) c

24. Causality-safety  Using many times the same operation may cause problems  For instance a may interact with d 24 a o ¡ ! b k c o ¡ ! d ( o ) a k( o ) b k( o ) c k( o ) d

25. Causality-safety  We define a causality relation between events of the projected POC  e 1 < e 2 if e 2 becomes enabled after e 1 has been performed  the exact definition depends on whether the semantics is synchronous or asynchronous  We require causality dependencies between events on the same operation  At most one of them can be enabled at the time  No interference 25

26. Roadmap  IOC and POC: two approaches to choreography  What does a IOC means?  Conditions for a correct projection  Behavioral correspondence  Conclusions 26

27. Bisimilarity  We characterize the behavioral relation between a IOC and the projected POC using (variations of) bisimilarity  A IOC and a POC are synchronous bisimilar iff  If then and and are bisimilar  Viceversa  This is standard strong bisimilarity  The other cases are formalized using variants bisimilarity 27 I 1 S 1 S 2 I 1 ® ¡ ! I 2 S 1 ® ¡ ! S 2 I 2

28. Other bisimilarities  Sender bisimilarity: IOC transitions are matched by POC sends, POC receives are abstracted away  weak w.r.t. POC receive transitions  Receiver bisimilarity: IOC transitions are matched by POC receives, POC sends are abstracted away  weak w.r.t. POC send transitions  Disjoint bisimilarity: a IOC transition is matched by subsequent send and receive POC transitions 28

29. Main result  A IOC is bisimilar to its projection  According to the synchronous/sender/receiver/disjoint bisimilarity  If it satisfies all the synchronous/sender/receiver/disjoint connectedness conditions 29

30. Receive bisimulation example 30 a o 1 ¡ ! b ;c o 2 ¡ ! b a o 1 ¡ ! b ¡¡¡¡ ! 1 ;c o 2 ¡ ! b c o 2 ¡ ! b ¡¡¡¡ ! 1

31. Receive bisimulation example (2) 31 a o 1 ¡ ! b ;c o 2 ¡ ! b a o 1 ¡ ! b ¡¡¡¡ ! 1 ;c o 2 ¡ ! b c o 2 ¡ ! b ¡¡¡¡ ! 1

32. Roadmap  IOC and POC: two approaches to choreography  What does a IOC means?  Conditions for a correct projection  Behavioral correspondence  Conclusions 32

33. Language extensions  Internal located actions, recursion and hiding can be added to the language  Value passing can be added  A role should own the values it sends  Values can be used to transform nondetermistic choice into deterministic 33

34. IOC simulations and POC simulations  (Bi)simulations can be defined both for IOCs and for POCs  Bisimulation between IOC and POC is compatible with those (bi)simulations  The projections of two (bi)similar IOCs are bisimilar  One can refine a IOC (e.g., adding auxiliary interactions) and derive a refined POC  Refinement can solve connectedness problems  Hiding is necessary to have more powerful refinements 34

35. Conclusion  We started from the basic question: which is the meaning of a IOC?  We derived different possible interpretations according to the choice of synchronous/asynchronous semantics and to the observable events  For each possibility  We found suitable syntactic conditions ensuring a correct projection  We characterized the behavioral relation between IOC and POC as a suitable bisimilarity relation 35

36. Future work  Complete the analysis on a more complex language  Recursion/iteration  Data  Hiding  Exceptions  Look at more complex projection functions  Should allow to relax the connectedness conditions  Study the possibility of refinement 36

37. 37

38. Related work  Carbone, Honda, Yoshida, “Structured communication- centred programming for web services”, ESOP ’07  Honda, Yoshida, Carbone, “Multiparty asynchronous session types”, POPL ’08  Bravetti, Zavattaro, “Towards a unifying theory for choreography conformance and contract compliance”, SC ’07  Busi et al., “Choreography and orchestration conformance for system design”, COORDINATION ’06  Li, Zhu, Pu, “Conformance validation between choreography and orchestration”, TASE ‘07 38