CS 290C: Formal Models for Web Software Lectures 14 and 15: Choreography and Orchestration Modeling with Process Algeb

1. CS 290C: Formal Models for Web Software Lectures 14 and 15: Choreography and Orchestration Modeling with Process Algebras Instructor: Tevfik Bultan

2. A Choreography Example • First, Buyer asks Seller, through a specified channel, to offer a quote • Then Seller replies with a quote • Buyer then answers with either QuoteAcceptance or QuoteRejection. • If the answer is QuoteAcceptance, then Seller sends a confirmation to Buyer, and request delivery details from the Shipper. Then Shipper sends the deliver details to Seller and Seller sends them to the Buyer and the protocol terminates. • If the answer is QuoteRejection, then the interaction terminates.

3. Example Choreography as a Conversation Protocol Buyer→Seller: RequestforQuote Seller→Buyer: QuoteResponse Seller→Buyer: OrderConfirmation Buyer→Seller: QuoteAcceptance Seller→Shipper: RequestDelDetails Buyer→Seller: QuoteReject Shipper→Seller: DeliveryDetails Seller→Buyer: DeliveryDetails

4. Example Choreography as an MSC Buyer Seller Shipper RequestForQuote QuoteResponse alt QuoteReject QuoteAcceptance OrderConfirmation RequestDelDetails DeliveryDetails DeliveryDetails

5. Example Choreography as Collaboration Diagrams Buyer 2:QuoteResponse 4:OrderConfirmation 7: DeliveryDetails 1:RequestForQuote 3:QuoteAcceptance 5:RequestDelDetails Seller Shipper 6:DeliveryDetails

6. Example Choreography as Collaboration Diagrams Buyer 1:RequestForQuote 3:QuoteReject 2:QuoteResponse Seller Shipper

7. Projections to Peers (Participants) Seller ?RequestforQuote !QuoteResponse !OrderConfirmation ?QuoteAcceptance !RequestDelDetails ?QuoteReject ?DeliveryDetails !DeliveryDetails

8. Projections to Peers (Participants) Buyer Shipper !RequestforQuote ?RequestDelDetails ?QuoteResponse !QuoteAcceptance !DeliveryDetails ?OrderConfirmation !QuoteReject ?DeliveryDetails

9. Process Algebras for Choreography & Orchestration • Another formalism for specifying choreography and orchestration • Process algebras and process calculi are extensively used in specification and verification • There are verification tools for analyzing process algebra specifications • If we specify choreography and orchestration specifications in process algebra we can use these analysis tools

10. Process Algebras for Choreography & Orchestration • The following paper report propose process algebras for choreography and orchestration • “A Theoretical Basis of Communication-Centred Concurrent Programming” by Marco Carbone, Kohei Honda, Nobuko Yoshida, Robin Milner, Gary Brown and Steve Ross-Talbot • The proposed process algebras are based on pi-calculus • The goal is to provide a theoretical foundation for the choreography specification languages such WS-CDL

11. Process Algebras for Choreography & Orchestration • There are two process algebras: • A process algebra for choreography specifications: • This is used for specifying global ordering of interactions, i.e., it specifies the global ordering of messages exchanged among the participants (peers) • A process algebra for orchestration: • This is used to specify control flow of participants, the ordering of their local actions and their send and receive operations

12. Process Algebras for Choreography & Orchestration • Given a uniform framework based on process algebras it is possible to define various analysis problems on choreography & orchestration using process algrebras such as • Realizability of choreography specifications • Projection of choreography specifications to each participant • Conformance of participant specifications to the global choreography specification • In the following slides, I will give a brief overview of these two process algebras • Read pages 5 to 15 from “A Theoretical Basis of Communication-Centred Concurrent Programming” to see an application of these process algebras to a simple example

13. A Process Algebra for Choreogrpahy I ::= A → B: ch(new vec(s)).I (init) | A → B:s<op, e, y>.I (com) | x@A := e.I (assign) | if e@A then I1 else I2 (ifthenelse) | I1 + I2 (sum) | I1 | I2 (par) | (new s) I (new) | XA (recVar) | rec XA.I (rec) | 0 (inaction)

14. A Process Algebra for Choreogrpahy A → B: b(new vec(s)).I A invokes a service b at B, initiating a new session that will use the fresh session channels vec(s) followed by interaction I A → B:s<op, e, y>.I A sends a message with operator op to B on channel s, the value of the expression e (which only refers to variables at A) becomes the value of variable y (which is a variable at B) x@A := e.I Assings the value of the expression e (evaluated at A) to variable x (also at A)

15. A Process Algebra for Choreogrpahy if e@A then I1 else I2 Evaluate e at A and execute I1 if it evaluates to true, otherwise execute I2 I1 + I2 Nondeterministic choice: Behaves either as I1 or I2 I1 | I2 Parallel execution: Starts two threads of execution, one behaves as I1 and the other as I2

16. A Process Algebra for Choreogrpahy (new s) I This expression binds free ocurences of session channel s in I. It is used to designate channels when a session is initiated. rec XA.I Used to specify recursive behavior, where XA denotes the recursion variable. The superscript A denotes that the peer A makes the decision on whether to recur or not. 0 Means inaction, typically used to denote termination of a thread of execution.

17. A Process Algebra for Peer Orchestration P ::= !ch(vec(s)).P (init-In) | bar(ch)(new vec(s)).P (init-Out) | s > sumiopi(xi).Pi (input) | s < op(e).P (output) | x := e.P (assignment) | if e then P1 else P2 (conditional) | P1 + P2 (internal sum) | P1 | P2 (parallel) | (new s) P (res) | X (variable) | rec X.P (recursion) | 0 (inaction)

18. A Process Algebra for Peer Orchestration !ch(vec(s)).P A service ch (maybe identified by an URL) that can be invoked by other services bar(ch)( vec(s)).P Denotes invocation of the service ch

19. A Process Algebra for Peer Orchestration s > sumiopi(xi).Pi Denotes a receipt of a message (one of opi) through the session channel s, the communicated value is assigned to the corresponding local variable xi s < op(e).P Denotes sending a message op through session channel s with value of the expression e x := e.P Denotes assignment of the value of the expression e to x

20. A Process Algebra for Peer Orchestration if e then P1 else P2 Evaluates e and behaves as P1 if it evaluates to true, otherwise behaves as P2 P1 + P2 Nondeterministic choice: Behaves either as P1 or P2 P1 | P2 Parallel execution: Starts two threads of execution, one behaves as P1 and the other as P2

21. A Process Algebra for Peer Orchestration (new s) P Means s is local to P rec X.P Recursion 0 Means inaction, typically used to denote termination of a thread of execution.

22. Reduction in Process Algebras • The behavior of process algebra specifications are defined by reduction rules • These are rules that define how the system transitions from one state to another state • The reduction rules are defined both for choreography and orchestration algebras

23. End Point Projection • End Point Projection means projection of the choreography specification to the local specifications • There has been work on this area similar to the work on realizability of conversation protocols, MSCs and collaboration diagrams, • A set of rules are defined that restrict the choreography specification in such a way that the end point projection generates a set of peer specifications that implement the choreography specification

24. Process Algebras • In order to demonstrate some concepts related to process algebras, I will use simpler process algebras then the ones described above which ignore the following: • channel passing • variables

25. A Process Algebra for Choreogrpahy I ::= A → B:m . I (com) | I1 + I2 (sum) | I1 | I2 (par) | XA (recVar) | rec XA.I (rec) | 0 (inaction) The above grammar defines the syntax of the choreography process algebra terms The sender and the receiver names in the communication event can be ignored if we assume that for each message type m, there is only one unique sender (send(m)=A) and one unique receiver (recv(m)=B)

26. Example Choreography as a Conversation Protocol Buyer→Seller: RequestforQuote Seller→Buyer: QuoteResponse Seller→Buyer: OrderConfirmation Buyer→Seller: QuoteAcceptance Seller→Shipper: RequestDelDetails Buyer→Seller: QuoteReject Shipper→Seller: DeliveryDetails Seller→Buyer: DeliveryDetails

27. Example Choreography in Process Algebra Buyer→Seller: RequestforQuote . Seller→Buyer: QuoteResponse . ( ( Buyer→Seller: QuoteReject . 0 ) + (Buyer→Seller: QuoteAcceptance . Seller→Buyer: OrderConfirmation . Seller→Shipper: RequestDelDetails . Shipper→Seller: DeliveryDetails . Seller→Buyer: DeliveryDetails . 0 ) )

28. Example Choreography in Process Algebra Buyer→Seller: RequestforQuote . Seller→Buyer: QuoteResponse . ( ( Buyer→Seller: QuoteReject . 0 ) + (Buyer→Seller: QuoteAcceptance . Seller→Buyer: OrderConfirmation . Seller→Shipper: RequestDelDetails . Shipper→Seller: DeliveryDetails . Seller→Buyer: DeliveryDetails . 0 ) )

29. A Process Algebra for Peer Orchestration P ::= !A: m . P (send) | ?A: ∑i mi . P (receive) | P1 + P2 (internal sum) | P1 | P2 (parallel) | X (variable) | rec X.P (recursion) | 0 (inaction) Syntax of the peer orchestration process algebra Send event sends message m to A. Receive event receives message m from A To simplify the model we can assume that for each message type m, there is only one unique sender (send(m)) and one unique receiver (recv(m)) and then we can drop A in send and receive actions

30. Projections to Peers (Participants) Seller ?RequestforQuote !QuoteResponse !OrderConfirmation ?QuoteAcceptance !RequestDelDetails ?QuoteReject ?DeliveryDetails !DeliveryDetails

31. End Point Projection Seller Process Orchestration: Seller[ ?Buyer: RequestforQuote . !Buyer: QuoteResponse . ( ( ?Buyer: QuoteReject . 0 ) + (?Buyer: QuoteAcceptance . !Buyer: OrderConfirmation . !Shipper: RequestDelDetails . ?Shipper: DeliveryDetails . !Buyer: DeliveryDetails . 0 ) ) ]

32. Projections to Peers (Participants) Buyer Shipper !RequestforQuote ?RequestDelDetails ?QuoteResponse !QuoteAcceptance !DeliveryDetails ?OrderConfirmation !QuoteReject ?DeliveryDetails

33. End Point Projection Buyer Process Orchestration: Buyer[ !Seller: RequestforQuote . ?Buyer: QuoteResponse . ( ( !Seller: QuoteReject . 0 ) + (!Seller: QuoteAcceptance . ?Seller: OrderConfirmation . ?Seller: DeliveryDetails . 0 ) ) ]

34. End Point Projection Shipper Process Orchestration: Shipper[ ?Seller: RequestDelDetails . !Seller: DeliveryDetails . 0 ]

35. A Process Algebra for Composition of Peers N ::= A[P] (peer) | N | M (parallel-n) | ε (inaction-n) The above grammar defines the syntax of peer composition process algebra (called networks) terms Compositions of peers are called networks. They correspond to message-passing composition of orchestration of peers

36. Composition of Peers Composition of Peers (network): Buyer[…] | Seller[…] | Shipper[…]

37. End Point Projection • As I discussed in earlier lectures, end point projection does not work if we simply map each send and receive actions to the related participants • We also need to put some restrictions on the choreography specifications for the end point projections to work • This is basically the same realizability problem I mentioned for other specification formalisms such as conversation protocols, message sequence charts and collaboration diagrams • There are also a set of realizability conditions for the process algebras for choreography specifications which guarantee that the end point projections of a given choreography that satisfy those conditions generate the same interactions as the choreography specification

38. Process Algebra Concepts • Using the simple orchestration process algebra as an example, I will define some interesting concepts used in process algebras such as: • Structural equivalence (congruence) • Reduction rules • Simulation relation • Bisimulation relation • Observational equivalence

39. Structural Equivalence (Congruence) • Process algebras enable us to manipulate specifications like mathematical terms. • There are set of structural equivalences that hold for each process algebra • These structural equivalences can be used in proving that two process specifications are equivalent

40. Structural Equivalence (Congruence) Structural equivalences for choreography algebra I+I ≡ I I1 + I2 ≡ I2 + I1 (+ is commutative) (I1 + I2) + I3 ≡ I1 + (I2 + I3) (+ is associative) I | 0 ≡ I I1 | I2 ≡ I2 | I1 (| is commutative) (I1 | I2) | I3 ≡ I1 | (I2 | I3) (| is associative)

41. Structural Equivalence (Congruence) Structural equivalences for orchestration algebra P+P ≡ P P1 + P2 ≡ P2 + P1 (+ is commutative) (P1 + P2) + P3 ≡ P1 + (P2 + P3) (+ is associative) P | 0 ≡ P P1 | P2 ≡ P2 | P1 (| is commutative) (P1 | P2) | P3 ≡ P1 | (P2 | P3) (| is associative)

42. Structural Equivalence (Congruence) Structural equivalences for peer composition N | 0 ≡ N N1 | N2 ≡ N2 | N1 (| is commutative)

43. Semantics of Process Algebras • We will define the semantics of process algebras as transition systems: • (S, M, T), where • S is the set of states • M is the set of messages • T is the transition relation where • T  S  M  S • This is a simplified model where only transitions we are allowing are message exchanges. Typically there would also be internal actions which would correspond to silent transitions

44. Transition relation notation • Given the transition system (S, M, T) and the transition relation T  S  M  S for (s,m,s’)  T we can equivalently write s → s’ m

45. Semantics of Process Algebras • The set of states of the transition system will correspond to process algebra expressions • The semantics of the process algebra will define how a process algebra expression reduces to another expression after an action execution (i.e., after a message exchange) • To explain all possible ways that a given process algebra expression can reduce to another process algebra expression we will define a set of reduction rules

46. Reduction Rules • Reductions rules are used to define the semantics of process algebras • They describe the behaviors of processes • Reduction rules can be explained using SOS (structural operation semantics) • In SOS, behavior of a system is explained using rules of the following form: • It means that if all the conditions above the line hold, then the condition below the line also holds premise1 premise2 … premisen conclusion

47. Reduction Rules for the Choreography Algebra m I A →B: m.I m m I I’ I I’ m m I | J I’ | J I’’ I’’’ I[rec XA . I / XA] I I’ I’ m m I + J I’ rec XA . I I’ m m I ≡ I’’ I ≡ I’’’

48. Reduction Rules for the Orchestration + Network m A[?B: ∑i mi . P] | B[!A:m .Q] A | B m m N N’ N N’ m m N | M N’ | M N’’ N’’’ A[P] | N A[P] | N A[P’] | N’ A[P’] | N’ A[P[rec X . P / X]] | N A[P’ ] | N’ m m m A[P+Q] | N A[P’ | Q] | N’ A[P | Q] | N A[P’] | N’ A[rec X . P] | N A[P’] | N’ mi = m m m m N ≡ N’’ N ≡ N’’’

49. Simulation • We say that J simulates I iff for all m  M • If I→I’ then there exists a J’ such that J→J’ and J’ simulates I’ • Nice property about simulation: • If J simulates I, then temporal properties (ACTL*) that hold on J will also hold for I • So if J is a simpler specification we can analyze/verify J instead of I, and conclude properties about I m m

50. Bimulation • We say that I and J are bisimulation equivalent iff for all m  M • If I→I’ then there exists a J’ such that J→J’ and I’ and J’ are bisimulation equivalent • Whenever J→J’ then there exists a I’ such that I→I’ and I’ and J’ are bisimulation equivalent • Nice property about bisimulation: • I and J satisfy the same set of temporal properties (CTL*) • Moreover I and J genrate the same set of conversations m m m m