choreography-driven design

Ivan Lanese Department of Computer Science

University of Bologna

INRIA research team FOCUS

Choreography-driven design

Joint work with:

Mario Bravetti, Gianluigi Zavattaro

Plan of the

From Choreography to Contracts Contract-based Service Discovery Conclusion

Plan of the Talk

Different models for interacting systems

Choreography (e.g. WS-CDL): Top abstract view of the system, composed by communications involving two of its participants

Orchestration (e.g. WS-BPEL) Set of contracts describing the components of the system, composed by sendings & receivings of messages

WS-CDL Global view of service interactions

Buyer

Seller

Bank

WS-CDL Global view of service interactions

Buyer

SellerRequest

Bank

WS-CDL Global view of service interactions

Buyer

Seller

PayDescr

RequestOffer

Bank

WS-CDL Global view of service interactions

Buyer

Seller

PayDescr

RequestOffer

Bank

Payment

WS-CDL Global view of service interactions

Buyer

Seller

PayDescr

RequestOffer

Bank

PaymentConfirm

Receipt

WS-CDL

RequestBuyerSeller ;

( OfferSellerBuyer |

PayDescrSellerBank ) ;

PaymentBuyerBank ;

( ConfirmBankSeller |

ReceiptBankBuyer )

Explicit representation of concurrency

Projection of the Choreography on the Single Participants

Buyer: Send(Request)@Seller;Receive(Offer); Send(Payment)@Bank;Receive(Receipt)

Seller: Receive(Request); (Send(Offer)@Buyer | Send(PayDescr)@Bank); Receive(Confirm)

Bank: Receive(PayDescr);Receive(Payment); (Send(Receipt)@Buyer | Send(Confirm)@Seller)

Well Formed WS-CDL Choreographies

Can we always project (in a simple way) a WS-CDL choreography by preserving its behavior?

Which kind of behavior is preserved?

A Formal Model for WS-CDL

A global choreography language:H ::= ars | 1 | 0 |

H;H | H+H | H|H

A Formal Model for WS-CDL

A global choreography language:H ::= ars | 1 | 0 |

H;H | H+H | H|Hr invokes the

operation a of s

Successful termination

Unsuccessful termination

A Formal Model for WS-CDL

A global choreography language:H ::= ars | 1 | 0 |

H;H | H+H | H|H

Choice

Sequence

Parallel

A Formal Model for orchestrations

A language for orchestrations:P ::= a | ar | 1 | 0 |

P;P | P+P | P|PS ::= [P]r | S|S

A Formal Model for orchestrations

A language for orchestrations:P ::= a | ar | 1 | 0 |

P;P | P+P | P|PS ::= [P]r | S|S

receive on a

Successful termination

Unsuccessful termination

invoke a at r

A Formal Model for orchestrations

Choice

Sequence

Parallel

A language for orchestrations:P ::= a | ar | 1 | 0 |

P;P | P+P | P|PS ::= [P]r | S|S

A Formal Model for orchestrations

A language for orchestrations:P ::= a | ar | 1 | 0 |

P;P | P+P | P|PS ::= [P]r | S|S

Behaviour of participant r

Parallel compositionof participants

The “canonical” projection

Projection [[ H ]]t of choreography H to participant t

as if t=r

[[ ars ]]t = a if t=s1 otherwise

[[H;H’]]t=[[H]]t ; [[H’]]t [[H|H’]]t=[[H]]t | [[H’]]t

[[H+H’]]t=[[H]]t + [[H’]]t

Essentially an homomorphism

Example

Consider the global choreography: ars ; btu

Projection: [ as ;1]r | [ a;1 ]s | [ 1;bu ]t | [ 1;b ]u

Are the two models equivalent? NO But, if r=t…. YES (synchronous)

[ as; bu ]r | [ a;1 ]s | [ 1;b ]u

Asynchronous communication

Reconsider the example assuming asynchronous communication

[ as; bu ]r | [ 1;a ]s | [ 1;b ]u

Communication on a starts before communication on b but could finish after

What we should observe? Send, receive, both, …?

A lattice of possible observation criteria

Sender Receiver

Sender-receiver

Synchronous

Disjoint

A lattice of possible observation criteria

Sender Receiver

Sender-receiver

Synchronous

Disjoint

Assuming synchronous communication: observe either send or receive

A lattice of possible observation criteria

Sender Receiver

Sender-receiver

Synchronous

Disjoint

Assuming asynchronous communication: observe send

A lattice of possible observation criteria

Sender Receiver

Sender-receiver

Synchronous

Disjoint

Assuming asynchronous communication: observe receive

A lattice of possible observation criteria

Sender Receiver

Sender-receiver

Synchronous

Disjoint

Assuming asynchronous communication: observe send and observe receive

A lattice of possible observation criteria

Sender Receiver

Sender-receiver

Synchronous

Disjoint

Assuming asynchronous communication: observe send and receive together

What about the previous example?

Reconsider the example ars ; bru

[ as; bu ]r | [ 1;a ]s | [ 1;b ]u

OK: for synchronous and sender NO: for receiver, sender-receiver,

disjoint

Main result

For each observation criterion: Sufficient syntactic conditions

(connectedness, unique point of choice, and causality safety) that guarantee that a choreography is equivalent to its projection

Unique point of choice

In a choice H+H’ The sender of the initial transitions in H and

in H’ is always the same The roles in H and in H’ are the same

Example: if we drop the second condition (ars + brt ); c st

[ ( as+bt );1]r | [ (a+1);ct ]s | [ (1+b);c ]t

Which equivalence between choreography and orchestration?

Synchronous equivalence: global transitions are matched by synchronous local transitions

Sender equivalence: global transitions are matched by local sends, local receives are abstracted away

weak w.r.t. local receive transitions Receiver equivalence: global transitions are matched

by local receives, local sends are abstracted away weak w.r.t. local send transitions

Sender-Receiver equivalence: both conditions above Disjoint equivalence: global transitions are matched

by a pair of a local send and a local receive

Example: Receiver equivalence

Global choreography: ars ; bts

Local choreography: [ 1;as ]r | [ a;b ]s | [ 1;bs ]t

The two systems are receiver equivalent

Amending choreographies

What can we do if a choreography does not satisfy the conditions? We can automatically transform it

into one that satisfies the conditions for disjoint equivalence

Preserving the “weak” traces We add actions which are used only for

synchronization and are not observed

Example: Amending choreographies

Original choreography: (ars | cru) ; bts

Amended choreography:

(ars ; h*sz|cru ; i*uz) ;j*zt ; bts

The two systems are now weak disjoint equivalent

Similar patterns for all the criteria

Which equivalence to choose?

Synchronous equivalence: if I have a synchronous system (easy )

Sender equivalence: ensures that data are available when needed

Receiver equivalence: ensures that invariants in the choreography hold in the projected system

Sender-Receiver equivalence: both the properties above

Disjoint equivalence: robust also in case of message loss

Example

Consider the global choreography: withdrawcustbank ; paycustshop

Projection:

[ wbank ;pshop]cust | [ 1;w ]bank | [ 1;p ]shop

In the choregraphy money is never created

In the system I can pay before the bank has updated my account amount

Example

In a receiver connected choreography this will not happen withdrawcustbank ; notifybankshop ;

paycustshop

Also in the projection the bank has updated the account before money can be spent

Plan of the

From Choreography to Contracts Contract-based service discovery Conclusion

Plan of the Talk

Contracts

Contract: service “behavioural interface” correct sequence

of invoke and receive just finite-state labeled

transition system with successful termination

Contract:abstract service

description

Service

public registry

Contract Compliance Verification of correctness of service

composition based on their contracts: successful interaction i.e. no deadlock / termination reached

Contract:abstract service

description

Service

…Contract:

abstract service description

Service …

public registry public registry

Reciprocal invocations

Service Compliance: Formally

Services are compliant if the following holds for their composition S:

S --->* S’ implies that there exist S’’ and S’’’ s.t. S’ --->* S’’ ---> S’’’

i.e. every computation can be extended to reach successful completion of all services

termination under fairness assumption

τ

√τ

Example: compliant services

The following pairs of services are compliant: C1 = a+b+c C2 = a + b C1 = a;b C2 = a | b C1 = (a; b )* C2 = a;

( b;a )*;b

…

Choreography

Compliance-Preserving Contract Refinement !

Contract

public registry

Contract

public registry

Service Service …Reciprocal invocations

Contract Part. 1 Contract Part. n…refines refines

compliance preserved by refinement

compliant by construction

projection projection

…

Choreography

Contract Refinement Relation

Contract

public registry

Contract

public registry

Service Service …Reciprocal invocations

Contract Part. 1 Contract Part. n…refines refines

compliance preserved by refinement

compliant by construction

Formally: Subcontract Preorder

C

sub-contracts

of C

subcontractpreorder

Preorder ≤ between contracts C: C’ ≤ C means C’ is a subcontract

of C

Definition of Preorder Induced from Independent Refinement

C1 C2 Cn

Given a set of compliant contracts

is a set of compliant contracts

subcontractpreorder

sub-contracts

of C2 …sub-contracts

of C1 sub-contracts

of Cn

C’1 C’2 C’n…

…

No maximal subcontract preorder … in general

Consider the system:[ a ] | [ a ]

we could have one preorder ≤1 for which

a + c.0 ≤1 a a + c.0 ≤1 a

and one preorder ≤2 for which

a + c.0 ≤2 a a + c.0 ≤2 a

but no subcontract preorder could havea + c.0 ≤ a a + c.0 ≤ a

Consequence: no independent refinement!

Maximal pre-order

It exists under some assumptions: Limiting the considered services

(output persistence) Strengthening the notion of

compliance (strong compliance) Moving to asynchronous

communication(e.g. via message queues)

Output persistence

Output persistence means that given a process state P: If P has an output action on a and

P-->P’ with different from output on a, then also P’ has an output on a

This holds, for instance, in WS-BPEL (without faults) Pick operator is input guarded

Difficult to force if mixed choice is used

Example

Given the choreography:RequestAliceBob; (AcceptBobAlice +

RejectBobAlice)

The following services can be retrieved:[τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

Example

Given the choreography:RequestAliceBob; (AcceptBobAlice +

RejectBobAlice)

The following services can be retrieved:[τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

[τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

Example

Given the choreography:RequestAliceBob; (AcceptBobAlice + RejectBobAlice)

The following services can be retrieved:[τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

[τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

[τ;RequestBob;(Accept+Reject+Retry)]Alice | [Request;τ;AcceptAlice]Bob

“Standard” Contract Compliance

Example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

“Standard” Contract Compliance

Example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

“Standard” Contract Compliance

Example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

“Standard” Contract Compliance

Example: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

Let us give a more careful look: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

Alternatives to Standard Compliance: Strong Compliance

Alternatives to Standard Compliance: Strong Compliance

Let us give a more careful look: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

Let us give a more careful look: S1: invoke(a);invoke(b) S2: receive(a);invoke(c) S3: receive(c);receive(b)

S1

S2

S3

Strong compliance requires that the receptors should be always ready

These services are not strongly compliant !!

Alternatives to Standard Compliance: Strong Compliance

Example: strong compliant services

The following pairs of services are strong compliant: C1 = a+b+c C2 = a + b C1 = a;b C2 = a | b C1 = (a; b )* C2 = a;

( b;a )*;b

Example: strong compliant services

The following pairs of services are strong compliant: C1 = a+b+c C2 = a + b C1 = a;b C2 = a | b C1 = (a; b )* C2 = a;

( b;a )*;b

“Strong” refinement

It allows also refinement on names already in the interface: Receive(a);(Receive(b)+Receive(a)) ≤ Receive(a);Receive(b)

Summary of Results “Normal” compliance:

Unconstrained contracts: maximal relation does not exist Contracts satisfying output persistence: maximal relation exists if

output alphabet of contracts is known Contracts satisfying output persistence where outputs are

directed to a location: maximal relation exists

Strong compliance: Unconstrained contracts (where output are directed to a

location):maximal relation exists

Queue-based compliance: Unconstrained contracts (where output are directed to a

location):maximal relation exists

Summary of Results Direct conformance w.r.t. the whole choreography:

maximal relation does not exist (all kinds of compl.) Sound characterizations of the relations obtained

(apart from the queue based) by resorting to an encoding into (a fair version of) must testing [RV05]

With respect to testing: both system and test must succeed As a consequence:

Algorithm that guarantees compliance Classification of the relations w.r.t. existing pre-orders: coarser

than (fair) must testing (e.g., they allow external non-determinism on inputs to be added in refinements)

Plan of the

From Choreography to Contracts Contract-based service discovery Conclusion

Plan of the Talk

Future work

Choreographies with dynamic participant creation

Contracts with operators for process interruption and compensation The contract language becomes

partially undecidable

Related work

Carbone, Honda, Yoshida Global and End-point calculus similar

to our choreography and orchestration

Only some of our observation criteria are considered

Stronger conditions for projection

Related work

Fu, Bultan, Su Service systems with message

queues similar to ours Observe the send event as in our

sender observation criterion No refinement

Related work

Padovani et al. Contracts described with an ad-hoc

transition system (reminiscent of acceptance tree)

The absence of maximal subcontract relation solved either with explicit interfaces or filters (cut the additional actions of the refinements)

Related work

van der Aalst et al. Contracts described with open workflow

nets (similar to petri nets) Same notion of compliance Same definition of subcontract as maximal

refinement that preserves compliance Characterization of the refinement for

processes without “loops” (make the system infinite due to message queues)

References M. Bravetti and G. Zavattaro. Contract based Multi-party Service

Composition. In FSEN’07. (full version in Fundamenta Informaticae) M. Bravetti and G. Zavattaro. Towards a Unifying Theory for Choreography

Conformance and Contract Compliance. In SC’07. M. Bravetti and G. Zavattaro. A Theory for Strong Service Compliance. In

Coordination’07. (full version in MSCS) M. Bravetti and G. Zavattaro. Contract Compliance and Choreography

Conformance in the presence of Message Queues.In WS-FM’08 M. Bravetti and G. Zavattaro. On the Expressive Power of Process

Interruption and Compensation. In WS-FM’08 I. Lanese, C. Guidi, F. Montesi, and G. Zavattaro. Bridging the Gap Between

Interaction- and Process-oriented Choreographies. In SEFM’08. M. Bravetti, I. Lanese, G. Zavattaro. Contract-Driven Implementation of

Choreographies.In TGC'08 M. Bravetti, G. Zavattaro. Contract-Based Discovery and Composition of Web

Services. In Formal Methods for Web Services, Advanced Lectures, LNCS 5569

M. Boreale, M. Bravetti. Advanced Mechanisms for Service Composition, Query and Discovery in Rigorous Software Eng. for Service-Oriented Systems, LNCS, to appear