bridging the gap between interaction- and process-oriented choreographies talk by ivan lanese joint...

Bridging the gap between Interaction-

and Process-Oriented Choreographies

Talk by Ivan LaneseJoint work with Claudio Guidi,

Fabrizio Montesi and Gianluigi ZavattaroUniversity of Bologna, Bologna, Italy

Roadmap

IOC and POC: two approaches tochoreography

What does a IOC means?

Conditions for a correct projection

Behavioral correspondence

Conclusions

2

Roadmap





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

6

hire

req. access

grant

confirm

ask payment

pay

notify

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 o1, followed by an input on o2

BPEL4CHOR

7

a o¡! b

(o1;o2)a

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

IOC syntax

basic interaction

empty IOC

terminated IOC

sequential composition

parallel composition

nondeterministic choice

9

I ::= a o¡! bj 1j 0j I 1; I 2j I 1 k I 2j I 1+I 2

Idea of IOC semantics

Semantics based on LTS Labels corresponding to basic interactions

and termination

10

a o¡! bp

a o1¡! b;b o2¡! c ao1¡! b¡¡ ¡ ¡! 1;b o2¡! c b

o2¡! c¡¡ ¡ ¡! 1p

¡! 0

POC syntax

role


output

input

empty POC

terminated POC

sequential composition


nondeterministic choice

11

S ::= (P )aj S1 k S2

P ::= oj oj 1j 0j P1;P2j P1jP2j P1+P2

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¡! bp

o : aa o¡! b

p

(o)a k (o)bo:a¡¡! (1jhoi)a k (o)b

ao¡! b¡¡ ¡!

(1j1)a k (1)bp

¡! (0)a k (0)b

Roadmap





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:

We look for conditions ensuring that such a projection behaves well

14

proj(a o¡! b;a) = o

proj(a o¡! b;c) = 1proj(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

16

a o1¡! b;c o2¡! d

A partial order

17

Stricter constraints on IOC

Stronger relation on behaviors

Disjoint

Sender Receiver

Sender - receiver

Synchronous

Roadmap





Conclusions

18


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 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 o1¡! b;c o2¡! 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

21

a o1¡! b;a o2¡! d

(o1;o2)a k (o1)b k (o2)d

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

Points of choice: example

If we drop the condition on roles:

In the projection

Interaction on O3 is enabled

23

(a o1¡! b+a o2¡! c);b o3¡! c

((o1+o2);1)a k ((o1+1);o3)b k ((1+o2);o3)c

Causality-safety

Using many times the same operation may cause problems

For instance a may interact with d

24

a o¡! bk 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 e1 < e2 if e2 becomes enabled after e1 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





Conclusions

26

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 S1S2I 1

®¡! I 2 S1®¡! S2 I 2

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

30

(o1;1)a k (o1;o2)b k (1;o2)co1:a¡ ¡ !

(1;1jho1i )a k (o1;o2)b k (1;o2)ca

o1¡! b¡¡ ¡ ¡!

(1;1j1)a k (1;o2)b k (1;o2)co2:c¡¡!

(1;1j1)a k (1;o2)b k (1jho2i )cc

o2¡! b¡¡ ¡ ¡!

(1;1j1)a k (1)b k (1j1)c

a o1¡! b;c o2¡! b ao1¡! b¡¡ ¡ ¡! 1;c o2¡! b c

o2¡! b¡¡ ¡ ¡! 1

Receive bisimulation example (2)

31

a o1¡! b;c o2¡! b ao1¡! b¡¡ ¡ ¡! 1;c o2¡! b c

o2¡! b¡¡ ¡ ¡! 1

(o1;1)a k (o1;o2)b k (1;o2)co2 :c¡¡!

(o1;1)a k (o1;o2)b k (1jho2i )co1 :a¡ ¡ !

(1;1jho1i )a k (o1;o2)b k (1jho2i )ca

o1¡! b¡¡ ¡ ¡!

(1;1j1)a k (1;o2)b k (1jho2i )cc

o2¡! b¡¡ ¡ ¡!

(1;1j1)a k (1)b k (1j1)c

Roadmap





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

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

bridging the gap between interaction- and process-oriented choreographies talk by ivan lanese joint...

Documents

o j o j

b slide

jh o i

ioc vs poc

poc behavior

roadmap ioc

service choreography

ioc syntax basic interaction