Orchestration vs Choreography - Plone siteOrchestration vs Choreography u In many cases, there is no...

Orchestration vs Choreography

u In many cases, there is no unique point of invocation for the services n  In these cases, we say that the system is a

choreography n  Let starts with an example:

w Consider the popular OpenID protocol for distributed authentication via third party services

Bertinoro 7-11/3/2016 Models and Languages for Service-Oriented and Cloud Computing

OpenID


1. User sends username

OpenID


2. Username is forwarded


OpenID



3. User sends password


OpenID



4. Authorized/ Not authorized



How to model choreographies?

u Several approaches are usually adopted to model (and program) choreographies n  MSC (Message Sequence Charts) n  Cryptographic protocol notation n  Open workflow nets n  Collaboration diagrams n  Process calculi-like languages n  …


Message Sequence Chart for OpenID




1. User sends username 2. Username is

forwarded




forwarded





forwarded


4. Authorized/ Not authorized

Chryptographic protocol notation

u (Part of the) Needham-Schroeder authentication with public key:

A → B: {nA, A}kB

B → A: {nA, nB}kA

A → B: {nB}kB



u A man-in-the-middle attack at the Needham-Schroeder protocol:

A → I: {nA, A}kI I → B: {nA, A}kB B → I: {nA, nB}kA I → A: {nA, nB}kA A → I: {nB}kI I → B: {nB}kB



u The patched Needham-Schroeder-Lowe protocol:

A → B: {nA, A}kB

B → A: {nA, nB, B}kA

A → B: {nB}kB


Open workflow nets


u Each partner is modeled by a Petri net with input/output places n  The partners are

combined by merging their input/output places

Collaboration diagram


Collaboration diagram


u Two kinds of dependencies among events

n  Local dependencies: total ordering of the events on the same channel (A2 follows A1)

n  Causal dependencies: A2/C2 indicates that C2 causally depends on A2

The process-calculus approach

u The process-calculus approach: n  Define the basic actions … n  ... define operators to combine actions thus

obtaining processes u Approach adopted in the most popular

choreography language in the context of Web Services: n  WS-CDL: Web Service Choreography

Description Language Bertinoro 7-11/3/2016 Models and Languages for Service-Oriented and Cloud Computing

WS-CDL approach u Global view of service interactions

Buyer

Seller

Bank Bertinoro 7-11/3/2016 Models and Languages for Service-Oriented and Cloud Computing


Buyer

Seller Request



Buyer

Seller

PayDescr

Request Offer



Buyer

Seller

PayDescr

Request Offer

Bank

Payment



Buyer

Seller

PayDescr

Request Offer

Bank

Payment Confirm

Receipt


WS-CDL approach

RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer )


WS-CDL approach



Basic Action Buyer sends a message

“Request” to Seller

WS-CDL approach



Sequential composition



WS-CDL approach



Sequential composition

Parallel composition



Interaction Oriented Approach

u In the WS-CDL approach the basic action corresponds to n  a sender that sends a message on an

operation exposed by a receiver n  this is the so-called global view approach

u Easy to formalise … we will see:

I. Lanese, C. Guidi, F. Montesi, G. Zavattaro: Bridging the Gap between Interaction- and Process-Oriented Choreographies. Proc. of SEFM 2008: 323-332


Choreography process calculus

u We have defined a choreography process calculus


Basic Action r sends a message a to s

Choice

Sequential

Parallel

Repetition

Choreography operational semantics


Ready to terminate

Final completion

A simple choreography (1)

u A client sends a reservation request to a travel agency, which contacts an airplane company and a hotel, and finally notify the client by confirming or cancelling the reservation:


A simple choreography (2)

u A client negotiates with a shop the price for a product she initially indicates


Subtleties in choreographies

u Suppose the decision to Decline is taken by the client:

u Are there possible problems with this choreography?


Possible problems

u Intuition: problems could depend on the kind of communication n  Synchronous: (no problem) client and

shop synchronise on the branch to select n  Asynchronous: (problem) client and shop

could select different branches (by emitting inconsistent messages)


Choreography correctness

u We have performed a formal study of choreography correctness n  A calculus for choreography (similar to

the previous one, without repetition) n  Canonical projection:

w syntactic extraction from the choreography of the behaviour of the single roles

n  Check that the parallel composition of the projections behaves like the choreography


IOC: Interaction Oriented Choreography calculus

u We have defined an Interaction Oriented Choreography (IOC) calculus


Basic Action a sends a message o to b

Sequence

Parallel Choice

IOC: Interaction Oriented Choreography calculus

u We have defined an Interaction Oriented Choreography (IOC) calculus


Success Failure

IOC: operational semantics


POC: Process Oriented Choreography calculus

u We have defined a Process Oriented Choreography (POC) calculus


Process P playing role a Choreography

Processes Receive Send

POC: operational semantics -Processes-


POC: operational semantics -Choreographies-


POC: the client-shop example

u Here is the behaviour of the client and the shop in the first of the two already considered choreographies:


POC: the client-shop example

u Here is the alternative version where the client sends the decline message:

u No problem: there are three possible

choices (Price, Confirm, and Decline) and the client / shop synchronize in taking this decision!


Formal correspondence u The IOC and the POC:

have exactly the same traces of transitions in the operational semantics

u Here is the alternative version where the client sends the decline message:

u No problem: there are three possible

choices (Price, Confirm, and Decline) and the client / shop synchronizes in taking this decision!


Canonical projection

u In the previous example, the behaviour of the roles in the POC is obtained from the IOC by means of projection:


The OpenID Example

u The OpenId IOC:

and the projected POC:

u No Problem! Same traces! Bertinoro 7-11/3/2016 Models and Languages for Service-Oriented and Cloud Computing

An alternative end of OpenID u Consider the following alternative end:

and its projection:


Choreography correctness

u Is it possible to check the correctness of a choreography? n  Yes: by controlling three independent

conditions w Connectedness for sequence w Unique point of choice w Causality safety


Connectedness for sequence

u Intuition: n  Given the choreography C;D the rhs D

should start only when the lhs C has completed

n  We check this condition by controlling that among the roles involved in the completion of C there is at least one role involved in the starting of D


Initial and final transitions u The functions transI and transF return

the interactions in the starting and completion of a choreography


Connectedness for sequence: formally


u The last action before a sequential composition will surely occur before every possible intial action after n  guaranteed by the involvement of at least

one role in both actions

Connectedness for sequence

u Here is a trivial example of an incorrect choreography:

having the following projection:


Unique point of choice

u Intuition: n  Given the choreography C+D all the

involved roles should agree on the branch to select: w When an initial action in one branch occur, all

the initial actions in the other one should be disabled

w The selected branch must be communicated to all partners, hence the partners involved in C and in D must be the same


Unique point of choice: formally


u Every pair of initial actions in the two branches must include a common role: n  this role will be the unique point of choice n  moreover, the selected branch must be

communicated to all involved roles

Unique point of choice

u Here is a trivial example of an incorrect choreography:

having the following projection:


Causality safety u Intuition:

n  If an operation occurs twice in a choreography, the two interactions should be not active contemporaneously

n  Consider the following choreography:

with the projection:


Causality safety: formally


u The relation ≤s formalises causal dependencies n  hence if x ≤s y the two events x and y

cannot be both ready to be executed

Exercise

u Which condition is not satisfied in the wrong alternative OpenID end?


Exercise


Connectedness for sequence: ?


Exercise


Connectedness for sequence: ✔


Exercise


Unique point of choice: ?


Exercise


Unique point of choice: ✔


Exercise


Causality safety: ?


Exercise


Causality safety: ✗


Let’s go back to the client-shop example

u Remember: possible problems if the

client sends Decline while the shop Price n  This could happen in asychronously

communicating systems Bertinoro 7-11/3/2016 Models and Languages for Service-Oriented and Cloud Computing

Asynchronous choreography correctness

u We have defined asychronous communication for POCs n  We have defined the correspondence

between IOCs and their asynchronous execution w More complex because send and receive events

are disjoint in POCs

n  We have revisited the three correctness conditions that guarantee correspondence


POC: Asynchronous semantics


Correspondence relation

u At the level of POC the interaction coincides with the receive event n  Hence, interaction correspondence

guarantees correspondence of receive (send could not correspond)

n  See the choreography:

with projection:


Several correspondence relations

u The previous correspondence is named receiver correspondence n  We have considered

a lattice of correspondence relations

n  In the literature, receiver seems the mainly considered correspondence


Receiver connectedness for sequence

u There are two ways to preserve the receive events in a sequential composition C ;D n  the receiver in C is the emitter in D

n  the receiver in C is also the receiver in D


Asynchronous unique point of choice

u In an asynchronous setting, the emitter can locally decide to send a message n  In a choice only the emitter decide a branch


Asynchronous causality safety


u Same definition, but with a relation ≤a that formalises causal dependencies for the asynchronous semantics

Exercise: the initial WS-CDL example




RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asynchronous unique point of choice: ?



RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asynchronous unique point of choice: ✔


Trivial


RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asynchronous causality safety: ?



RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asynchronous causality safety: ✔


Trivial


RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asychronous connectedness: ?



RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; PaymentBuyeràBank ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asychronous connectedness: ✔


Exercise: try to remove the Payment RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; ( ConfirmBankàSeller | ReceiptBankàBuyer )


Exercise: try to remove the Payment RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asynchronous unique point of choice: ✔


Trivial

Exercise: try to remove the Payment RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asynchronous causality safety: ✔


Trivial

Exercise: try to remove the Payment RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asychronous connectedness: ?


Exercise: try to remove the Payment RequestBuyeràSeller ; ( OfferSelleràBuyer | PayDescrSelleràBank ) ; ( ConfirmBankàSeller | ReceiptBankàBuyer ) Asychronous connectedness: ✗


In an asynchronous setting there is no ordering guarantee (while it is guaranteed for synchronous communication!)

What to do with choreographies ? u You are now among the greatest

worldwide experts in choreographies! n  so what? …

u Don’t worry... you didn’t lose your time n  There is at least one programming

language that you can use to realise your distributed systems using choreographies

Marco Carbone, Fabrizio Montesi: Deadlock-freedom-by-design: multiparty asynchronous global programming. Proc. of POPL 2013: 263-274


Choreography programming

u A IOC-like language is used to specify the possible communication protocols used in the system

u An enriched choreography language (variables, if-then-else, functions, ..) is used to specify the overall system

u End-point programs are obtained by means of projection (written in Jolie)


The approach: graphically


Chor: basic ideas

u Describe the behaviour of processes in a system: n  Each process has a local state n  Processes take part to multiparty

conversations, tracked as sessions n  Sessions are started through public

channels (e.g., URLs). n  Both sessions and processes can be

dynamically created Bertinoro 7-11/3/2016 Models and Languages for Service-Oriented and Cloud Computing


Alice and Bob buy a book together

Orchestration vs Choreography - Plone siteOrchestration vs Choreography u In many cases, there is no...

Documents

Transcript of Orchestration vs Choreography - Plone siteOrchestration vs Choreography u In many cases, there is no...