Bridging the gap between Interactionand ProcessOriented Choreographies Talk

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

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

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

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

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

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

IOC vs POC § There are two different approaches to choreography § Interaction-Oriented Choreography (IOC) § describes the conversation from a globalapoint ¡!o of b 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. (o 1 ; o 2 ) a § a performs an output on o 1, followed by an input on o 2 § BPEL 4 CHOR 7

From design to implementation § IOCs are more easy to understand 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

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

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

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

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

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

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: !o = proj(a ¡ b; a) o proj(a ¡!o b; b) = o proj(a ¡!o b; c) = 1 § We look for conditions ensuring that such a projection behaves well 14

15

What ; means? § Consider theosimple IOC o a ¡ !1 b; c ¡ !2 d § 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 partial order Disjoint Stricter constraints on IOC Sender - receiver Sender Receiver Stronger relation on behaviors Synchronous 17

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

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

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

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

Points of choice § IEnsures + J 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

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

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

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

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

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

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

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

Receive bisimulation example o!1 o!2 ¡ ¡ a ¡o!1 b; c ¡o!2 b ¡¡a ¡ ¡ !b 1; c ¡o!2 b ¡¡c ¡ ¡!b 1 (o 1 ; 1) a k (o 1 ; o 2 ) b k (1; o 2 ) c (1; 1 jho 1 i ) a k (o 1 ; o 2 ) b k (1; o 2 ) c (1; 1 j 1) a k (1; o 2 ) b k (1 jho 2 i ) c ! ¡o¡ 1 : a o a ¡ !1 !b ¡¡ ¡ ¡ ¡o¡ 2 !: c o c¡ !2 !b ¡¡ ¡ ¡ (1; 1 j 1) a k (1) b k (1 j 1) c 30

Receive bisimulation example (2) o!1 o!2 ¡ ¡ a ¡o!1 b; c ¡o!2 b ¡¡a ¡ ¡ !b 1; c ¡o!2 b ¡¡c ¡ ¡!b 1 (o 1 ; 1) a k (o 1 ; o 2 ) b k (1; o 2 ) c (o 1 ; 1) a k (o 1 ; o 2 ) b k (1 jho 2 i ) c (1; 1 jho 1 i ) a k (o 1 ; o 2 ) b k (1 jho 2 i ) c (1; 1 j 1) a k (1; o 2 ) b k (1 jho 2 i ) c ¡o¡ 2 !: c ! ¡o¡ 1 : a o!1 ¡ ¡¡a ¡ ¡ !b o c¡ !2 !b ¡¡ ¡ ¡ (1; 1 j 1) a k (1) b k (1 j 1) c 31

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

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

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

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

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

Related work § Carbone, Honda, Yoshida, “Structured communicationcentred 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