choreography-driven design
Post on 03-Jan-2016
60 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related