CS 290 C Formal Models for Web Software

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

A Choreography Example 1. First, Buyer asks Seller, through a specified channel, to offer a quote 2. Then Seller replies with a quote 3. Buyer then answers with either Quote. Acceptance or Quote. Rejection. 1. If the answer is Quote. Acceptance, 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. 2. If the answer is Quote. Rejection, then the interaction terminates.

Example Choreography as a Conversation Protocol Buyer→Seller: Requestfor. Quote Seller→Buyer: Quote. Response Seller→Buyer: Order. Confirmation Buyer→Seller: Quote. Acceptance Seller→Shipper: Request. Del. Details Buyer→Seller: Quote. Reject Shipper→Seller: Delivery. Details Seller→Buyer: Delivery. Details

Example Choreography as an MSC Buyer Seller Shipper Request. For. Quote. Response alt Quote. Reject Quote. Acceptance Order. Confirmation Request. Del. Details Delivery. Details

Example Choreography as Collaboration Diagrams Buyer 1: Request. For. Quote 3: Quote. Acceptance 2: Quote. Response 4: Order. Confirmation 7: Delivery. Details 5: Request. Del. Details Seller Shipper 6: Delivery. Details

Example Choreography as Collaboration Diagrams Buyer 1: Request. For. Quote 2: Quote. Response 3: Quote. Reject Seller Shipper

Projections to Peers (Participants) Seller ? Requestfor. Quote !Quote. Response !Order. Confirmation ? Quote. Acceptance !Request. Del. Details ? Quote. Reject ? Delivery. Details !Delivery. Details

Projections to Peers (Participants) Buyer Shipper !Requestfor. Quote ? Request. Del. Details ? Quote. Response !Quote. Acceptance !Quote. Reject ? Delivery. Details ? Order. Confirmation !Delivery. Details

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

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

Process Algebras for Choreography & Orchestration • There are two process algebras: 1. 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) 2. 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

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

A Process Algebra for Choreogrpahy: Syntax Here is the grammar that defines the syntax of the choreography process algebra: I : : = | | | | | A → B: ch(new vec(s)). I A → B: s<op, e, y>. I x@A : = e. I if e@A then I 1 else I 2 I 1 + I 2 I 1 | I 2 (new s) I XA rec XA. I 0 (init) (com) (assign) (ifthenelse) (sum) (par) (new) (rec. Var) (rec) (inaction)

A Process Algebra for Choreogrpahy: Semantics 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), followed by interaction I x@A : = e. I Assings the value of the expression e (evaluated at A) to variable x (also at A), followed by interaction I

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

A Process Algebra for Choreogrpahy: Semantics (new s) I This expression binds free occurences 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.

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

A Process Algebra for Peer Orchestration: Semantics !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

A Process Algebra for Peer Orchestration: Semantics 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

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

A Process Algebra for Peer Orchestration: Semantics (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.

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

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

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

A Simplified Process Algebra for Choreography I : : = | | | A → B: m. I I 1 + I 2 I 1 | I 2 XA rec XA. I 0 (com) (sum) (par) (rec. Var) (rec) (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)

Example Choreography as a Conversation Protocol Buyer→Seller: Requestfor. Quote Seller→Buyer: Quote. Response Seller→Buyer: Order. Confirmation Buyer→Seller: Quote. Acceptance Seller→Shipper: Request. Del. Details Buyer→Seller: Quote. Reject Shipper→Seller: Delivery. Details Seller→Buyer: Delivery. Details

Example Choreography in Process Algebra Buyer→Seller: Requestfor. Quote. Seller→Buyer: Quote. Response. ( ( Buyer→Seller: Quote. Reject. 0 ) + (Buyer→Seller: Quote. Acceptance. Seller→Buyer: Order. Confirmation. Seller→Shipper: Request. Del. Details. Shipper→Seller: Delivery. Details. Seller→Buyer: Delivery. Details. 0 ) )

A Simplified Process Algebra for Peer Orchestration P : : = !A: m. P (send) | ? A: ∑i mi. P (receive) | P 1 + P 2 (internal sum) | P 1 | P 2 (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

Projections to Peers (Participants) Seller ? Requestfor. Quote !Quote. Response !Order. Confirmation ? Quote. Acceptance !Request. Del. Details ? Quote. Reject ? Delivery. Details !Delivery. Details

End Point Projection Seller Process Orchestration: Seller[ ? Buyer: Requestfor. Quote. !Buyer: Quote. Response. ( ( ? Buyer: Quote. Reject. 0 ) + (? Buyer: Quote. Acceptance. !Buyer: Order. Confirmation. !Shipper: Request. Del. Details. ? Shipper: Delivery. Details. !Buyer: Delivery. Details. 0 ) ) ]

Projections to Peers (Participants) Buyer Shipper !Requestfor. Quote ? Request. Del. Details ? Quote. Response !Quote. Acceptance !Quote. Reject ? Delivery. Details ? Order. Confirmation !Delivery. Details

End Point Projection Buyer Process Orchestration: Buyer[ !Seller: Requestfor. Quote. ? Seller: Quote. Response. ( ( !Seller: Quote. Reject. 0 ) + (!Seller: Quote. Acceptance. ? Seller: Order. Confirmation. ? Seller: Delivery. Details. 0 ) ) ]

End Point Projection Shipper Process Orchestration: Shipper[ ? Seller: Request. Del. Details. !Seller: Delivery. Details. 0 ]

A Process Algebra for Composition of Peers N : : = A[P] | N|M | ε (peer) (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

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

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

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

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

Structural Equivalence (Congruence) Structural equivalences for choreography algebra I+I ≡ I I 1 + I 2 ≡ I 2 + I 1 (I 1 + I 2) + I 3 ≡ I 1 + (I 2 + I 3) (+ is commutative) (+ is associative) I|0≡I I 1 | I 2 ≡ I 2 | I 1 (I 1 | I 2) | I 3 ≡ I 1 | (I 2 | I 3) (| is commutative) (| is associative)

Structural Equivalence (Congruence) Structural equivalences for orchestration algebra P+P≡P P 1 + P 2 ≡ P 2 + P 1 (P 1 + P 2) + P 3 ≡ P 1 + (P 2 + P 3) (+ is commutative) (+ is associative) P|0≡P P 1 | P 2 ≡ P 2 | P 1 (P 1 | P 2) | P 3 ≡ P 1 | (P 2 | P 3) (| is commutative) (| is associative)

Structural Equivalence (Congruence) Structural equivalences for peer composition N|0≡N N 1 | N 2 ≡ N 2 | N 1 (| is commutative)

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

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 m s’ →

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

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: premise 1 premise 2 … premisen conclusion • It means that if all the conditions above the line hold, then the condition below the line also holds

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

Simulation • We say that J simulates I iff for all m M 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

Bimulation • We say that I and J are bisimulation equivalent iff for all m M m m – If I→I’ then there exists a J’ such that J→J’ and I’ and J’ are bisimulation equivalent m m – Whenever J→J’ then there exists a I’ such that I→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

Bisimulation and Choreography • We can check if a given choreography and its end point projections satisfy the bisimulation relation to guarantee that the end point projections correctly implement the choreography • This would be a way to formalize the notion of conformance between a choreography and its local implementations • We can say that a set of local peer implementations conform to a given choreography specification if we can find a bisimulation relation between the choreography specification and the local peer implementations

Observational Equivalence • Actually things are a little more complicated in reality • In practice the local processes (peers) will have internal actions and bisimulation equivalence could be a very strong requirement • Instead, we need to differentiate between the internal actions (which are not observable) and external actions (like message exchange) which are observable • Observational equivalence is the concept used for defining such equivalences • Observational equivalence can also be defined in the process algebra framework, however, the semantics will get a little more complicated since we have to accommodate internal actions and silent transitions

Summary • Process algrabras are concise formalism for specifying concurrent and distributed system. • They provide very minimal syntax to express very complicated behaviors • Their semantics can be concisely defined using SOS • They provide many equivalence definitions such as structural, bisimulation, observational equivalance • These equivalance relations are useful in verifying many different types of properties (including temporal logic properties or concepts such as choreography conformance as we have seen)