Orchestration vs Choreography

Transcription

1 Orchestration vs Choreography u In many cases, there is no unique point of invocation for the services n In these cases, we say that the system is a choreography n Let starts with an example: w Consider the popular OpenID protocol for distributed authentication via third party services

2 OpenID 1. User sends username

3 OpenID 2. Username is forwarded 1. User sends username

4 OpenID 2. Username is forwarded 1. User sends username 3. User sends password

5 OpenID 2. Username is forwarded 4. Authorized/ Not authorized 1. User sends username 3. User sends password

6 How to model choreographies? u Several approaches are usually adopted to model (and program) choreographies n MSC (Message Sequence Charts) n Cryptographic protocol notation n Open workflow nets n Collaboration diagrams n Process calculi-like languages n

7 Message Sequence Chart for OpenID

8 Message Sequence Chart for OpenID 1. User sends username

9 Message Sequence Chart for OpenID 1. User sends username 2. Username is forwarded

10 Message Sequence Chart for OpenID 1. User sends username 2. Username is forwarded 3. User sends password

11 Message Sequence Chart for OpenID 1. User sends username 2. Username is forwarded 3. User sends password 4. Authorized/ Not authorized

12 Chryptographic protocol notation u (Part of the) Needham-Schroeder authentication with public key: A B: {n A, A} kb B A: {n A, n B } ka A B: {n B } kb

13 Chryptographic protocol notation u A man-in-the-middle attack at the Needham-Schroeder protocol: A I: {n A, A} ki I B: {n A, A} kb B I: {n A, n B } ka I A: {n A, n B } ka A I: {n B } ki I B: {n B } kb

14 Chryptographic protocol notation u The patched Needham-Schroeder- Lowe protocol: A B: {n A, A} kb B A: {n A, n B, B} ka A B: {n B } kb

15 Open workflow nets u Each partner is modeled by a Petri net with input/output places n The partners are combined by merging their input/output places

16 Collaboration diagram

17 Collaboration diagram u Two kinds of dependencies among events n Local dependencies: total ordering of the events on the same channel (A2 follows A1) n Causal dependencies: A2/C2 indicates that C2 causally depends on A2

18 The process-calculus approach u The process-calculus approach: n Define the basic actions n... define operators to combine actions thus obtaining processes u Approach adopted in the most popular choreography language in the context of Web Services: n WS-CDL: Web Service Choreography Description Language

19 WS-CDL approach u Global view of service interactions Seller Buyer Bank

20 WS-CDL approach u Global view of service interactions Request Seller Buyer Bank

21 WS-CDL approach u Global view of service interactions Buyer Request Offer PayDescr Seller Bank

22 WS-CDL approach u Global view of service interactions Buyer Request Offer Payment PayDescr Seller Bank

23 WS-CDL approach u Global view of service interactions Buyer Request Offer Payment Receipt Seller PayDescr Confirm Bank

24 WS-CDL approach Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer )

25 WS-CDL approach Basic Action Buyer sends a message Request to Seller Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer )

26 WS-CDL approach Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Basic Action Buyer sends a message Request to Seller Sequential composition

27 WS-CDL approach Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Basic Action Buyer sends a message Request to Seller Sequential composition Parallel composition

28 Interaction Oriented Approach u In the WS-CDL approach the basic action corresponds to n a sender that sends a message on an operation exposed by a receiver n this is the so-called global view approach u Easy to formalise we will see: I. Lanese, C. Guidi, F. Montesi, G. Zavattaro: Bridging the Gap between Interaction- and Process-Oriented Choreographies. Proc. of SEFM 2008:

29 Choreography process calculus u We have defined a choreography process calculus Choice Parallel Basic Action r sends a message a to s Sequential Repetition

30 Choreography operational semantics Ready to terminate Final completion

31 A simple choreography (1) u A client sends a reservation request to a travel agency, which contacts an airplane company and a hotel, and finally notify the client by confirming or cancelling the reservation:

32 A simple choreography (2) u A client negotiates with a shop the price for a product she initially indicates

33 Subtleties in choreographies u Suppose the decision to Decline is taken by the client: u Are there possible problems with this choreography?

34 Possible problems u Intuition: problems could depend on the kind of communication n Synchronous: (no problem) client and shop synchronise on the branch to select n Asynchronous: (problem) client and shop could select different branches (by emitting inconsistent messages)

35 Choreography correctness u We have performed a formal study of choreography correctness n A calculus for choreography (similar to the previous one, without repetition) n Canonical projection: w syntactic extraction from the choreography of the behaviour of the single roles n Check that the parallel composition of the projections behaves like the choreography

36 IOC: Interaction Oriented Choreography calculus u We have defined an Interaction Oriented Choreography (IOC) calculus Sequence Basic Action a sends a message o to b Parallel Choice

37 IOC: Interaction Oriented Choreography calculus u We have defined an Interaction Oriented Choreography (IOC) calculus Success Failure

38 IOC: operational semantics

39 POC: Process Oriented Choreography calculus u We have defined a Process Oriented Choreography (POC) calculus Processes Receive Send Choreography Process P playing role a

40 POC: operational semantics -Processes-

41 POC: operational semantics -Choreographies-

42 POC: the client-shop example u Here is the behaviour of the client and the shop in the first of the two already considered choreographies:

43 POC: the client-shop example u Here is the alternative version where the client sends the decline message: u No problem: there are three possible choices (Price, Confirm, and Decline) and the client / shop synchronize in taking this decision!

44 Formal correspondence u The IOC and the POC: have exactly the same traces of transitions in the operational semantics

45 Canonical projection u In the previous example, the behaviour of the roles in the POC is obtained from the IOC by means of projection:

46 The OpenID Example u The OpenId IOC: and the projected POC: u No Problem! Same traces!

47 An alternative end of OpenID u Consider the following alternative end: and its projection:

48 An alternative end of OpenID u Consider the following alternative end: and its projection:

49 Choreography correctness u Is it possible to check the correctness of a choreography? n Yes: by controlling three independent conditions w Connectedness for sequence w Unique point of choice w Causality safety

50 Connectedness for sequence u Intuition: n Given the choreography C;D the rhs D should start only when the lhs C has completed n We check this condition by controlling that among the roles involved in the completion of C there is at least one role involved in the starting of D

51 Initial and final transitions u The functions transi and transf return the interactions in the starting and completion of a choreography

52 Connectedness for sequence: formally u The last action before a sequential composition will surely occur before every possible intial action after n guaranteed by the involvement of at least one role in both actions

53 Connectedness for sequence u Here is a trivial example of an incorrect choreography: having the following projection:

54 Unique point of choice u Intuition: n Given the choreography C+D all the involved roles should agree on the branch to select: w When an initial action in one branch occur, all the initial actions in the other one should be disabled w The selected branch must be communicated to all partners, hence the partners involved in C and in D must be the same

55 Unique point of choice: formally u Every pair of initial actions in the two branches must include a common role: n this role will be the unique point of choice n moreover, the selected branch must be communicated to all involved roles

56 Unique point of choice u Here is a trivial example of an incorrect choreography: having the following projection:

57 Causality safety u Intuition: n If an operation occurs twice in a choreography, the two interactions should be not active contemporaneously n Consider the following choreography: with the projection:

58 Causality safety: formally u The relation s formalises causal dependencies n hence if x s y the two events x and y cannot be both ready to be executed

59 Causality safety: formally u The relation s formalises causal dependencies n hence if x s y the two events x and y cannot be both ready to be executed

60 Exercise u Which condition is not satisfied in the wrong alternative OpenID end?

61 Exercise u Which condition is not satisfied in the wrong alternative OpenID end? Connectedness for sequence:?

62 Exercise u Which condition is not satisfied in the wrong alternative OpenID end? Connectedness for sequence:

63 Exercise u Which condition is not satisfied in the wrong alternative OpenID end? Unique point of choice:?

64 Exercise u Which condition is not satisfied in the wrong alternative OpenID end? Unique point of choice:

65 Exercise u Which condition is not satisfied in the wrong alternative OpenID end? Causality safety:?

66 Exercise u Which condition is not satisfied in the wrong alternative OpenID end? Causality safety:

67 Let s go back to the client-shop example u Remember: possible problems if the client sends Decline while the shop Price n This could happen in asychronously communicating systems

68 Asynchronous choreography correctness u We have defined asychronous communication for POCs n We have defined the correspondence between IOCs and their asynchronous execution w More complex because send and receive events are disjoint in POCs n We have revisited the three correctness conditions that guarantee correspondence

69 POC: Asynchronous semantics

70 POC: Asynchronous semantics

71 Correspondence relation u At the level of POC the interaction coincides with the receive event n Hence, interaction correspondence guarantees correspondence of receive (send could not correspond) n See the choreography: with projection:

72 Several correspondence relations u The previous correspondence is named receiver correspondence n We have considered a lattice of correspondence relations n In the literature, receiver seems the mainly considered correspondence

73 Receiver connectedness for sequence u There are two ways to preserve the receive events in a sequential composition C ;D n the receiver in C is the emitter in D n the receiver in C is also the receiver in D

74 Receiver connectedness for sequence u There are two ways to preserve the receive events in a sequential composition C ;D n the receiver in C is the emitter in D n the receiver in C is also the receiver in D

75 Asynchronous unique point of choice u In an asynchronous setting, the emitter can locally decide to send a message n In a choice only the emitter decide a branch

76 Asynchronous causality safety u Same definition, but with a relation a that formalises causal dependencies for the asynchronous semantics

77 Asynchronous causality safety u Same definition, but with a relation a that formalises causal dependencies for the asynchronous semantics

78 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer )

79 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Asynchronous unique point of choice:?

80 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Trivial Asynchronous unique point of choice:

81 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Asynchronous causality safety:?

82 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Asynchronous causality safety: Trivial

83 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Asychronous connectedness:?

84 Exercise: the initial WS-CDL example Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; Payment BuyeràBank ; ( Confirm BankàSeller Receipt BankàBuyer ) Asychronous connectedness:

85 Exercise: try to remove the Payment Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; ( Confirm BankàSeller Receipt BankàBuyer )

86 Exercise: try to remove the Payment Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; ( Confirm BankàSeller Receipt BankàBuyer ) Trivial Asynchronous unique point of choice:

87 Exercise: try to remove the Payment Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; ( Confirm BankàSeller Receipt BankàBuyer ) Asynchronous causality safety: Trivial

88 Exercise: try to remove the Payment Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; ( Confirm BankàSeller Receipt BankàBuyer ) Asychronous connectedness:?

89 Exercise: try to remove the Payment Request BuyeràSeller ; ( Offer SelleràBuyer PayDescr SelleràBank ) ; ( Confirm BankàSeller Receipt BankàBuyer ) In an asynchronous setting there is no ordering guarantee (while it is guaranteed for synchronous communication!) Asychronous connectedness:

90 What to do with choreographies? u You are now among the greatest worldwide experts in choreographies! n so what? u Don t worry... you didn t lose your time n There is at least one programming language that you can use to realise your distributed systems using choreographies Marco Carbone, Fabrizio Montesi: Deadlock-freedom-by-design: multiparty asynchronous global programming. Proc. of POPL 2013:

91 Choreography programming u A IOC-like language is used to specify the possible communication protocols used in the system u An enriched choreography language (variables, if-then-else, functions,..) is used to specify the overall system u End-point programs are obtained by means of projection (written in Jolie)

92 The approach: graphically

93 Chor: basic ideas u Describe the behaviour of processes in a system: n Each process has a local state n Processes take part to multiparty conversations, tracked as sessions n Sessions are started through public channels (e.g., URLs). n Both sessions and processes can be dynamically created

94 Alice and Bob buy a book together

95 Alice and Bob buy a book together

96 Alice and Bob buy a book together

97 Alice and Bob buy a book together

98 Alice and Bob buy a book together

99 Alice and Bob buy a book together

100 Alice and Bob buy a book together

101 Alice and Bob buy a book together

102 Alice and Bob buy a book together

103 Alice and Bob buy a book together

104 Alice and Bob buy a book together

105 Alice and Bob buy a book together