Bridging the gap between Interaction- and Process-Oriented Choreographies

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

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

3
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

3
4
Service Oriented Computing

• A paradigm for programming distributed
  applications by combining services
• Evolved from object-oriented and component
  computing
• A service is a piece of code that can be
• Dynamically found on the net based on its
  description
• Invoked and integrated in a large application
• Services are
• Platform and language independent
• Loosely coupled

4
5
Service Oriented Computing features

• SOC applications can integrate services from
  different companies
• Fundamental in business processing
• SOC allows for great dynamicity and reusability
• New versions of services immediately integrated
  in existing applications
• Applications can be easily adapted to changing
  requirements
• Based on international standards
• SOAP for communication
• WSDL for describing service interfaces
• UDDI for describing service repositories
• BPEL for combining services

5
6
Service choreography

• Communication is the main aspect of SOC
  applications
• Services interact via complex multiparty
  conversations
• A service choreography is the description of the
  possible conversation patterns

6
7
Providing my ticket to Lisbon
7
8
Service choreography languages

• We need languages to describe choreographies
• Two main approaches
• Interaction-Oriented Choreography global
  description
• Process-Oriented Choreography local description
• (Terminology not standardized yet)

8
9
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

9
10
Interaction-Oriented Choreography (IOC)

• Describes the conversation from a global point of
  view
• As composition of interactions
• Specifies what should happen without saying how
  to do it
• Easy to write and to understand
• Difficult to implement
• Good tool for design
• At the basis of WS-CDL

10
11
IOC syntax

• basic
  interaction
• empty IOC
• terminated IOC
• sequential
  composition
• parallel
  composition
• 
  nondeterministic choice

11
12
Idea of IOC semantics

• Semantics based on LTS
• Labels corresponding to basic interactions
  and termination

12
13
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

13
14
Process-Oriented Choreography (POC)

• Describes each participant of the conversation
  (roles)
• The behavior of each of them is described in
  terms of inputs and outputs
• Difficult to understand what is going on
• Easy to implement
• Good starting point for implementation
• At the basis of BPEL4CHOR

14
15
POC syntax

• role
• parallel
  composition
• output
• input
• empty process
• terminated
  process
• sequential
  composition
• parallel
  composition
• 
  nondeterministic choice

15
16
Idea of POC semantics

• Semantics based on LTS
• Two possible semantics
• Synchronous output and input interact directly
• Asynchronous the output spawns a message that is
  catched by the input

16
17
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

17
18
Idea of POC semantics

• Semantics based on LTS
• Two possible semantics
• Synchronous output and input interact directly
• Asynchronous the output spawns a message that is
  catched by the input
• Labels corresponding to message spawning
  , interaction .
  and termination

18
19
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

19
20
From design to implementation

• IOCs are good for design
• POCs are more easily implementable
• We want an automatic translation from IOCs to
  POCs
• Should preserve the intended semantics
• We project the IOC on each role to derive its
  behavior
• We compose the behaviors of the different roles
• We want the resulting POC to follow the IOC
  semantics

20
21
What does "follow the IOC semantics" means?
21
22
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

22
23
A partial order
Disjoint
Sender - receiver
Stricter constraints on IOC
Sender
Receiver
Stronger relation on behaviors
Synchronous
23
24
Projection

• We consider a natural projection
• is the projection of IOC
  over role a
• The projection is an homomorphism but for
• The resulting POC is the parallel composition of
  the projections on all the roles
• We look for conditions ensuring that such a
  projection behaves well

24
25
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

25
26
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)

26
27
Connectedness for sequence

• Ensures the correctness of sequential composition
• Synchronous a,b n c,d ? Ø
• Sender ac or bc
• Receiver bc or bd
• Disjoint bc
• The conditions can be generalized to ensure the
  connectedness of
• Conditions should be applied to final transitions
  of and initial transitions of

27
28
Example

• Consider
• The projection is
• The POC behaves well for synchronous and sender
  semantics
• The POC is not connected for receiver or disjoint
  semantics

28
29
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

29
30
Points of choice example

• If we drop the condition on roles
• In the projection
• Interaction on O3 is enabled

30
31
Causality-safety

• Using many times the same operation may cause
  problems
• For instance a may interact with d

31
32
Causality-safety

• We define a causality relation between events of
  the projected POC
• e1 lt 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 each time
• No interference

32
33
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

33
34
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
• Implies trace equivalence

34
35
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

35
36
Main result

• A IOC is bisimilar to its projection
• According to the synchronous/sender/receiver/disjo
  int bisimilarity
• If it satisfies all the synchronous/sender/receive
  r/disjoint connectedness conditions

36
37
Receive bisimulation example
37
38
Receive bisimulation example (2)
38
39
Roadmap

• Choreography in SOC
• The global view IOC
• The local view POC
• Projection from IOC to POC
• Correctness conditions
• Behavioral correspondence
• Conclusions

39
40
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/asynchronou
  s 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

40
41
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

41
42
Language extensions

• We want to extend the theory to deal with
• Internal located actions
• Recursion
• Hiding
• Useful for refinement
• Value passing can be added
• A role should own the values it sends
• Values can be used to transform nondetermistic
  choice into deterministic
• Exceptions

42
43
Other possible developments

• Look at smarter projection functions
• Should allow to relax the connectedness
  conditions
• May be related to refinement

43
44
Thanks!
Questions?
44
45
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

45