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

Roadmap  IOCs and POCs  Different interpretations for IOC  Connectedness conditions  Bisimilarity results  Conclusions 2

Roadmap  IOCs and POCs  Different interpretations for IOC  Connectedness conditions  Bisimilarity results  Conclusions 3

Choreography  Choreography aims at describing the interactions among many participants  Interaction-Oriented Choreography (IOC): obtained by composing basic interactions using composition operators  WS-CDL  Process-Oriented Choreography (POC): obtained as the parallel composition of the behavior of different roles  BPEL4CHOR, natural extension of orchestration language BPEL 4 a o ¡ ! b

From design to implementation  IOCs are more easy to understand and to write  Good tool for design  POCs are more easily implementable  We want to translate automatically a IOC into a POC  We project the IOC on the different roles 5

6

Interaction-oriented Choreography  Allows to describe interactions from a global point of view 7 I :: = a o ¡ ! b j 1 j 0 j I ; I 0 j I k I 0 j I + I 0

Process-oriented Choreography  Allows to compose the behaviours of different roles  Behaviours are based on input/output on operations  We give two semantics to POCs: a synchronous and an asynchronous one 8 P :: = o j o j 1 j 0 j P ; P 0 j P j P 0 j P + P 0 S :: = ( P ) a j S k S 0

Asynchronous behaviours 9

Composing behaviours 10  In the synchronous semantics the output is immediately propagated and matched with the input

Roadmap  IOCs and POCs  Different interpretations for IOC  Connectedness conditions  Bisimilarity results  Conclusions 11

Our aim  Given a IOC we want to project it onto roles to get a POC exhibiting the corresponding behaviors  The projection is an homomorphism but for:  We look for connectedness conditions ensuring that such a projection behaves well  The conditions and the meaning of “behaves well” depend on the interpretation of the IOC 12 pro j ( a o ¡ ! b ; a ) = o pro j ( a o ¡ ! b ; c ) = 1 pro j ( a o ¡ ! b ; b ) = o

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 13 a o 1 ¡ ! b ; c o 2 ¡ ! d

A partial order 14 Disjoint SenderReceiver Sender - receiver Synchronous Strincter constraints on IOC Stronger relation on behaviors

Roadmap  IOCs and POCs  Different interpretations for IOC  Connectedness conditions  Bisimilarity results  Conclusions 15

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 16 a o 1 ¡ ! b ; c o 2 ¡ ! d I ; J

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

Points of choice  Ensures the correctness of choice  Synchronous:  The same role should occur in each initial transitions  The roles in the two components should be the same  Asynchronous:  The sender should be the same  The roles in the two components should be the same 18 I + J

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

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

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 21

Roadmap  IOCs and POCs  Different interpretations for IOC  Connectedness conditions  Bisimilarity results  Conclusions 22

Bisimilarity  We characterize the behavioral relation between a IOC and the projected POC using bisimilarity  Synchronous bisimilarity: IOC transitions are matched by synchronous POC transitions  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 23

Main result  If a IOC satisfies all the connectedness conditions for the synchronous/sender/receiver/disjoint semantics then it is synchronous/sender/receiver/disjoint bisimilar to its projection 24

Receive bisimulation example 25 a o 1 ¡ ! b ; c o 2 ¡ ! b ( o 1 ; 1 ) a k( o 1 ; o 2 ) b k( 1 ; o 2 ) c ( 1 ; 1 jh o 1 i) a k( o 1 ; o 2 ) b k( 1 ; o 2 ) c ( o 1 ; 1 ) a k( o 1 ; o 2 ) b k( 1 jh o 2 i) c ( 1 ; 1 jh o 1 i) a k( o 1 ; o 2 ) b k( 1 jh o 2 i) c a o 1 ¡ ! b

Receive bisimulation example 26 1 ; c o 2 ¡ ! b ( 1 ; 1 j 1 ) a k( 1 ; o 2 ) b k( 1 jh o 2 i) c ( 1 ; 1 j 1 ) a k( 1 ; o 2 ) b k( 1 ; o 2 ) c c o 2 ¡ ! b 1 c o 2 ¡ ! b ( 1 ; 1 j 1 ) a k( 1 ) b k( 1 j 1 ) c

Roadmap  IOCs and POCs  Different interpretations for IOC  Connectedness conditions  Bisimilarity results  Conclusions 27

Extensions  Internal located actions, recursion and hiding can be added to the language  Value passing can be added  A role should own the value to be sent  Values can be used to transform nondetermistic choice into deterministic 28

Bisimulation  Bisimulations and simulations can be defined both for IOCs and for POCs  IOC-POC bisimulation 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 29

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 characterize the behavioral relation between IOC and POC as a suitable bisimulation relation 30

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 31

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

33