CS 290C: 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 QuoteAcceptance or
QuoteRejection.
1. 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.
2. If the answer is QuoteRejection, then the interaction
terminates.
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
Example Choreography as an MSC
Buyer
Seller
Shipper
RequestForQuote
QuoteResponse
alt
QuoteReject
QuoteAcceptance
OrderConfirmation
RequestDelDetails
DeliveryDetails
DeliveryDetails
Example Choreography as Collaboration Diagrams
Buyer
1:RequestForQuote
3:QuoteAcceptance
2:QuoteResponse
4:OrderConfirmation
7: DeliveryDetails
5:RequestDelDetails
Seller
Shipper
6:DeliveryDetails
Example Choreography as Collaboration Diagrams
Buyer
1:RequestForQuote
2:QuoteResponse
3:QuoteReject
Seller
Shipper
Projections to Peers (Participants)
Seller
?RequestforQuote
!QuoteResponse
!OrderConfirmation
?QuoteAcceptance
!RequestDelDetails
?QuoteReject
?DeliveryDetails
!DeliveryDetails
Projections to Peers (Participants)
Buyer
Shipper
!RequestforQuote
?RequestDelDetails
?QuoteResponse
!QuoteAcceptance
!QuoteReject
?DeliveryDetails
?OrderConfirmation
!DeliveryDetails
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 I1 else I2
I1 + I2
I1 | I 2
(new s) I
XA
rec XA.I
0
(init)
(com)
(assign)
(ifthenelse)
(sum)
(par)
(new)
(recVar)
(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 I1 else I2
Evaluate e at A and execute I1 if it evaluates to true, otherwise
execute I2
I 1 + I2
Nondeterministic choice: Behaves either as I1 or I2
I1 | I 2
Parallel execution: Starts two threads of execution, one
behaves as I1 and the other as I2
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 P1 else P2
P1 + P2
P1 | P2
(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 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
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
I1 + I2
I1 | I 2
XA
rec XA.I
0
(com)
(sum)
(par)
(recVar)
(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:
RequestforQuote
Seller→Buyer:
QuoteResponse
Seller→Buyer:
OrderConfirmation
Buyer→Seller:
QuoteAcceptance
Seller→Shipper:
RequestDelDetails
Buyer→Seller:
QuoteReject
Shipper→Seller:
DeliveryDetails
Seller→Buyer:
DeliveryDetails
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 )
)
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 )
)
A Simplified 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
Projections to Peers (Participants)
Seller
?RequestforQuote
!QuoteResponse
!OrderConfirmation
?QuoteAcceptance
!RequestDelDetails
?QuoteReject
?DeliveryDetails
!DeliveryDetails
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 )
)
]
Projections to Peers (Participants)
Buyer
Shipper
!RequestforQuote
?RequestDelDetails
?QuoteResponse
!QuoteAcceptance
!QuoteReject
?DeliveryDetails
?OrderConfirmation
!DeliveryDetails
End Point Projection
Buyer Process Orchestration:
Buyer[
!Seller: RequestforQuote .
?Seller: QuoteResponse . (
( !Seller: QuoteReject . 0 )
+
(!Seller: QuoteAcceptance .
?Seller: OrderConfirmation .
?Seller: DeliveryDetails . 0 )
)
]
End Point Projection
Shipper Process Orchestration:
Shipper[
?Seller: RequestDelDetails . !Seller: DeliveryDetails . 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
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 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
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
I1 + I2 ≡ I2 + I1
(I1 + I2) + I3 ≡ I1 + (I2 + I3)
(+ is commutative)
(+ is associative)
I|0≡I
I 1 | I 2 ≡ I2 | I 1
(I1 | I2) | I3 ≡ I1 | (I2 | I3)
(| is commutative)
(| is associative)
Structural Equivalence (Congruence)
Structural equivalences for orchestration algebra
P+P≡P
P1 + P2 ≡ P2 + P1
(P1 + P2) + P3 ≡ P1 + (P2 + P3)
(+ is commutative)
(+ is associative)
P|0≡P
P1 | P2 ≡ P2 | P1
(P1 | P2) | P3 ≡ P1 | (P2 | P3)
(| is commutative)
(| is associative)
Structural Equivalence (Congruence)
Structural equivalences for peer composition
N|0≡N
N1 | N2 ≡ N2 | N1
(| 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 sm→ 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:
premise1
premise2
…
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’ | J
I ≡ I’’
I
I’’
m
m
I’
I’’’
I
I
I+J
I ≡ I’’’
m
I’
m
I’
I[rec XA . I / XA] m
rec XA . I
m
I’
I’
Reduction Rules for the Orchestration + Network
mi = m
A[?B: ∑i mi . P] | B[!A:m .Q]
A[P] | N m
A[P | Q] | N
N m
N|M m
A[P’ | Q] | N’
N’
N’ | M
N ≡ N’’ N m
N’ N ≡ N’’’
N’’ m N’’’
A[P] | B[Q]
A[P] | N m
A[P’] | N’
m
m
A[P’] | N’
A[P+Q] | N m
A[P’] | N’
A[P[rec X . P / X]] | N m
A[rec X . P] | N
m
A[P’ ] | N’
A[P’] | N’
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 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)