cs 290c: formal models for web software lectures 14 and 15: choreography and orchestration modeling...

CS 290C: Formal Models for Web Software

Lectures 14 and 15: 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

Buyer→Seller:QuoteReject

Seller→Buyer: OrderConfirmation

Buyer→Seller:QuoteAcceptance

Seller→Shipper: RequestDelDetails

Shipper→Seller: DeliveryDetails

Seller→Buyer: DeliveryDetails

Example Choreography as an MSC

Seller ShipperBuyer

RequestForQuote

QuoteResponse

alt

QuoteAcceptance

QuoteReject

OrderConfirmation

RequestDelDetails

DeliveryDetails

DeliveryDetails

1:RequestForQuote

3:QuoteAcceptance

Seller

Buyer

Shipper

2:QuoteResponse

4:OrderConfirmation

7: DeliveryDetails

5:RequestDelDetails

6:DeliveryDetails

Example Choreography as Collaboration Diagrams

1:RequestForQuote

3:QuoteReject

Seller

Buyer

Shipper

2:QuoteResponse

Example Choreography as Collaboration Diagrams

Projections to Peers (Participants)

?RequestforQuote

!QuoteResponse

?QuoteReject

!OrderConfirmation

?QuoteAcceptance

!RequestDelDetails

?DeliveryDetails

!DeliveryDetails

Seller


!RequestforQuote

?QuoteResponse

!QuoteReject ?OrderConfirmation

!QuoteAcceptance

?DeliveryDetails

Buyer

Shipper

?RequestDelDetails

!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


• 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


• 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


• 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 → 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)


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


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


!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


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


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


(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


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)

Example Choreography as a Conversation Protocol

Buyer→Seller: RequestforQuote

Seller→Buyer: QuoteResponse

Buyer→Seller:QuoteReject

Seller→Buyer: OrderConfirmation

Buyer→Seller:QuoteAcceptance

Seller→Shipper: RequestDelDetails

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 )

)


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


?RequestforQuote

!QuoteResponse

?QuoteReject

!OrderConfirmation

?QuoteAcceptance

!RequestDelDetails

?DeliveryDetails

!DeliveryDetails

Seller


Seller Process Orchestration:

Seller[

?Buyer: RequestforQuote .

!Buyer: QuoteResponse . (

( ?Buyer: QuoteReject . 0 )

+

(?Buyer: QuoteAcceptance .

!Buyer: OrderConfirmation .

!Shipper: RequestDelDetails .

?Shipper: DeliveryDetails .

!Buyer: DeliveryDetails . 0 )

)

]


!RequestforQuote

?QuoteResponse

!QuoteReject ?OrderConfirmation

!QuoteAcceptance

?DeliveryDetails

Buyer

Shipper

?RequestDelDetails

!DeliveryDetails


Buyer Process Orchestration:

Buyer[

!Seller: RequestforQuote .

?Buyer: QuoteResponse . (

( !Seller: QuoteReject . 0 )

+

(!Seller: QuoteAcceptance .

?Seller: OrderConfirmation .

?Seller: DeliveryDetails . 0 )

)

]


Shipper Process Orchestration:

Shipper[

?Seller: RequestDelDetails . !Seller: DeliveryDetails . 0

]

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

Composition of Peers

Composition of Peers (network):

Buyer[…] | Seller[…] | Shipper[…]


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


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)


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

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:

• It means that if all the conditions above the line hold, then the condition below the line also holds

premise1 premise2 … premisen

conclusion

Reduction Rules for the Choreography Algebra

A →B: m.I

Im

I I’m

I | J I’ | JmI I’

I + J I’m

m

I I’m

I’’ I’’’m

I ≡ I’’ I ≡ I’’’ I[rec XA . I / XA] I’

rec XA . I

I’m

m

Reduction Rules for the Orchestration + Network

A[?B: ∑i mi . P] | B[!A:m .Q] A | Bm

A[P] | N A[P’] | N’

A[P+Q] | N A[P’] | N’m

m

N N’m

N’’ N’’’m

N ≡ N’’ N ≡ N’’’

A[P[rec X . P / X]] | N A[P’ ] | N’

A[rec X . P] | N A[P’] | N’m

m

mi = m

A[P] | N A[P’] | N’

A[P | Q] | N A[P’ | Q] | N’m

m

N N’m

N | M N’ | Mm

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

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

Bisimulation and Choreography

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

• So, 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)

cs 290c: formal models for web software lectures 14 and 15: choreography and orchestration modeling...

Documents

choreography orchestration

orchestration process

deliverydetails seller

choreography example

choreography specifications

process algebras instructor

proposed process algebras

process calculi