© 2012 metamaxim ltd modelling choreography ashley mcneile 1 st february 2012

© 2012 Metamaxim Ltd

Modelling Choreography

Ashley McNeile1st February 2012


Background


Agenda

• A little background• Introduction to Protocol Modelling– A way of modelling rich interaction between state,

data, and behaviour– Concerned with behaviour description using

composition (composition of partial descriptions)• Application to Choreography– Multiparty asynchronous collaborations– Reasoning a realizability


“Pure” Process Algebra

Closed

OpenB0

B1

B2

B-1

B-2

D2

D2

D2

D1

D1

D1

D1 W2

W2

W2

W1

W1

W1

W1

Close

Close

Close Ability to Express Ability to Reason

• Bank Account• Balance values in range -2 to +2• Deposit events D1 and D2• Withdraw events W1 and W2• Close only possible when “in credit”

ACCOUNT = Open B0B0 = D1 B1 | D2 B2 | W1 B-1 | W2 B-2 | Close ClosedB1 = D1 B2 | W1 B0 | W2 B-1 | Close ClosedB2 = W1 B1 | W2 B0 | Close ClosedB-1 = D1 B0 | D2 B1 | W1 B-2B-2 = D1 B-1 | D2 B0


Composition

Tony Hoare

Deterministic Choice P QChoice determined by the environment on the basis of the first action.

Nondeterministic ChoiceP ∏ Q

The environment has no control over the choice.

InterleavingP ||| Q

Completely independent concurrent activity.

Interface ParallelP || Q

Concurrent activity that requires synchronization between the component processes.


Eclipsed by “OOP mania” in 1980s and 1990s.

Early ideas in OO (1980s) Domain Object Behaviour

JSD (Jackson System Development) Shlaer/Mellor (Recursive Design)

M.A. Jackson

Bank Account

Transaction

In UseOpen Close

Deposit Withdraw

*

o o

Diagrams used to describe and formalise

“object life-cycles.”

Objects own data (like OO)

balance := balance + Deposit.amount;

balance := balance - Withdraw.amount;

balance := 0;

Composition not emphasized


Protocol Modelling


Protocol Modelling

OpenActive Closed

Close

Deposit

Withdraw



balance := 0;

Account Machine 1

Open

Un-frozen

Withdraw

Account Machine 2

Frozen

Release

Freeze

Release

Close

In Credit

State Function: if (balance < 0) return “Overdrawn”; else return “In Credit”;

Account Machine 3

Over-drawn


Protocol Modelling

OpenActive Closed

Close

Deposit

Withdraw



balance := 0;

Account Machine 1

Open

Un-frozen

Withdraw

Account Machine 2

Frozen

Release

Freeze

Release

Close

In Credit


Account Machine 3

Over-drawn

OpenActive Closed

Close

Deposit

Withdraw



balance := 0;

Account Machine 1

Open

Un-frozen

Withdraw

Account Machine 2

Frozen

Release

Freeze

Release

Close

In Credit


Account Machine 3

Over-drawn

Account = Account Machine 1 || Account Machine 2 ||Account Machine 3


Protocol Modelling

Active Closed

Account Machine 1

Un-frozen

Account Machine 2

Frozen

In Credit


Account Machine 3

Over-drawn

Open

Release

Close

balance = ??

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze



balance := 0;

Release

Close

balance = 0

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze


Protocol ModellingWithdraw 20

Active Closed

Account Machine 1

Un-frozen

Account Machine 2

Frozen

In Credit


Account Machine 3

Over-drawn



balance := 0;

Release

Close

balance = 0

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze

Release

Close

balance = -20

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze


Protocol ModellingClose

Active Closed

Account Machine 1

Un-frozen

Account Machine 2

Frozen

In Credit


Account Machine 3

Over-drawn



balance := 0;

Release

Close

balance = -20

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze

X


Protocol ModellingFreeze

Active Closed

Account Machine 1

Un-frozen

Account Machine 2

Frozen

In Credit


Account Machine 3

Over-drawn



balance := 0;

Release

Close

balance = -20

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze

Release

Close

balance = -20

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze


Protocol ModellingWhat Now?

Active Closed

Account Machine 1

Un-frozen

Account Machine 2

Frozen

In Credit


Account Machine 3

Over-drawn



balance := 0;

Release

Close

balance = -20

Close

Deposit

Withdraw

Open

Open

Withdraw

Release

Freeze


Protocol Modelling

OpenActive Closed

Close

Deposit

Withdraw



balance := 0;

Account Machine 1

Open

Un-frozen

Withdraw

Account Machine 2

Frozen

Release

Freeze

Release

Close

In Credit


Account Machine 3

Over-drawn

Topological(State is drivenby transitions)

Non-Topological

(State is calculated)

OpenActive Closed

Close

Deposit

Withdraw



balance := 0;

Account Machine 1

Open

Un-frozen

Withdraw

Account Machine 2

Frozen

Release

Freeze

Release

Close

In Credit


Account Machine 3

Over-drawn


Construction of AM1||AM2

d1Open

Active ClosedClose

Deposit

Withdraw

Open

Un-frozen

Withdraw

Frozen

Release

Freeze

d2

Deposit

ReleaseFreeze

Close

Deposit

Close

Close

DepositWithdraw

Open

ReleaseFreeze ReleaseFreeze

Closed,Frozen

Closed,Un-frozen

Active,Un-frozen

Active,Frozen

d1,d2

AM2

AM1||AM2Closed,

d2Active,

d2

d1,Frozen

d1,Un-frozen

AM1


Choreography


Dancer 4

Dance Choreography

Dancer 1

Dancer 3

Dancer 2


Scenario

• Messages are FIFO between each pair• The network does not block• How do we ensure that the collaboration “works”?


Step 1: Design the Choreography

P Q

R

m1 , m6

m2

m3 , m7 , m8 m5 m4

P>Q:m1Q>P:m2

Q>R:m3

P>R:m5R>P:m4

P>Q:m6

Q>R:m7

Q>R:m8

The labels on transitions show message exchanges.

P>Q:m1 denotes P sending a message of type m1 to Q.


Q>R:m3

Q>R:m7

Q>R:m8

P>Q:m1Q>P:m2

Step 2: Project to Participants

P

P>Q:m1Q>P:m2

P>R:m5R>P:m4

P>Q:m6

!>Q:m1

?<R:m4

!>Q:m6

!>R:m5

?<Q:m2


P

Step 2: Project to Participants

!>Q:m1

?<R:m4

!>Q:m6

!>R:m5

?<Q:m2

!>Q:m1

?<R:m4

!>Q:m6

!>R:m5

?<Q:m2

R

?<Q:m3

!>P:m4 ?<P:m5

?<Q:m7?<Q:m8

Q

?<P:m1!>P:m2

!>R:m3 ?<P:m6

!>R:m7

!>R:m8


P

Step 3: “Enact”

!>Q:m1

?<R:m4

!>Q:m6

!>R:m5

?<Q:m2

R

?<Q:m3

!>P:m4 ?<P:m5

?<Q:m7?<Q:m8

Q

?<P:m1!>P:m2

!>R:m3 ?<P:m6

!>R:m6

!>R:m7Will the emergent behaviour of the collaboration follow the original choreography?

• Imagine a “global clock”• On each tick, one thing happens: one send or one receive• Does the ordering of sends match a trace of the

choreography?


Some Examples

P QP>Q:m1

Q>P:m2

m1

m2

P Qm1

m2

P>Q:m1

Q>P:m2

No!

Yes!

P Qm1

m2

P>Q:m1 Q>P:m2

Yes!


Some Examples

P>Q:m1 Q>R:m2 P>R:m3P Qm1

m2

Rm3 No!

P>Q:m1 Q>P:m3

R>Q:m2 Q>P:m3

P Qm1

m2

R

m3 Yes!


The Rules (Simplified!)• Within a single choreography machine:

1. Only one sender from given state of the choreography2. No Send must take place from an ambiguous state

-

Q

-

Q

P

RP>Q:m1

Q>P:m2

Q>R:m3

P>R:m5R>P:m4

P>Q:m6 Q>R:m7

Q>R:m8

P !>Q:m1

?<R:m4

!>Q:m6

!>R:m5

?<Q:m2

?<P:m1!>P:m2

!>R:m3 ?<P:m6!>R:m6

!>R:m7

?<Q:m3

!>P:m4 ?<P:m5

?<Q:m7?<Q:m8


Scenario

Place OrderRequest CancelRequest Amend

Accept OrderAccept AmendAccept CancelInvoice

Request Credit Check

Request DepositPayment Receipt

Pay DepositPay Order

Credit OKDeposit Paid

Request Delivery

Request Delivery Date

Confirm Delivery Date

SUPPLIERCUSTOMER

DELIVERY CO

BANK

972

98

45

13

6

1

2

3

4

5

6

7

8

9

C S B D


C S B D Choreography 1

D]

Cust > Supp: RequestCancel

Supp > Cust:Accept Cancel

Supp > Cust:RejectCancel

Cust > Supp:PlaceOrder

Supp > Cust: AcceptOrder

Cust > Supp:Request Amend

Supp > Cust: Accept Amend

Supp > Cust: Reject AmendSupp > Cust: RejectOrder



D] Supp > Cust:AcceptOrder

Supp > Cust: Invoice

Cust > Bank:Pay Order

Bank > Cust: PaymentReceipt


Supp > Cust:Accept Amend

Cust > Supp:Place Order

Cust > Bank: Pay Deposit

Supp > Bank:Request Credit

Check

Bank > Supp:Credit OK

Bank > Cust:Request Deposit

Bank > Supp: Deposit Paid



D]

Supp > Cust:Accept Order

Supp > Del:Request Delivery

Del > Cust:Request

Delivery Date

Cust > Del:Confirm

Delivery Date

Del > Supp:Confirm

Delivery Date


Supp > Cust: AcceptCancel



Composition

D]Supp > Cust:Accept Order

Supp > Del:Request Delivery

Del > Cust:Request

Delivery Date

Cust > Del:Confirm

Delivery Date

Del > Supp:Confirm

Delivery Date


Supp > Cust: AcceptCancel


D]

Cust > Supp: RequestCancel


Supp > Cust:RejectCancel

Cust > Supp:PlaceOrder

Supp > Cust: AcceptOrder

Cust > Supp:Request Amend

Supp > Cust: Accept Amend

Supp > Cust: Reject AmendSupp > Cust: RejectOrder

D] Supp > Cust:AcceptOrder


Cust > Bank:Pay Order

Bank > Cust: PaymentReceipt



Cust > Supp:Place Order

Cust > Bank: Pay Deposit

Supp > Bank:Request Credit

Check

Bank > Supp:Credit OK

Bank > Cust:Request Deposit

Bank > Supp: Deposit Paid

CSB

D

S

S

S

C B

S

S C

B

DC SS

-

-

-

-

-

-


Reasoning with DataMoney Transfer by Instalment

1 Request

QP 2 Instalment

3 “Thanks”

P sends a Request for money to Q

Q starts sends instalments to P.

Once the cumulative instalments sent reaches the

requested amount, Q stops sending and P says “Thanks”.

Process:

1

2

3

State Function:if (toPay ≤ 0) return “done”;else return “not done”;

doneP>Q:“Thanks”not

done

Q>P:InstalmentC2

P>Q:Request

toPay := Request.amount;

Q>P:Instalment

P>Q:“Thanks”

toPay := toPay - Instalment.amount;

C1

CHOREOGRAPHY = C1 || C2


C2* (Connected Form of C2)

Reasoning with Data

State Function:if (toPay ≤ 0) return “done”;else return “not done”;

doneP>Q:“Thanks”not

done

Q>P:InstalmentC2

P>Q:“Thanks”Q>P:Instalment

P>Q:Request

Q>P:Instalment

Q>P:Instalment

not done done

P>Q:Request

toPay := Request.amount;

Q>P:Instalment

P>Q:“Thanks”

toPay := toPay - Instalment.amount;

C1

P>Q:“Thanks”Q>P:Instalment

C1 || C2* Q>P:Instalment

Q P -P>Q:Request

P

© 2012 metamaxim ltd modelling choreography ashley mcneile 1 st february 2012

Documents

balance deposit

credit account machine

oo balance

un frozen account machine

active closed account

over drawn account

w2 close

close closed b1