1 / 71

Choreography-driven design

Choreography-driven design. Ivan Lanese. Department of Computer Science University of Bologna INRIA research team FOCUS. Joint work with: Mario Bravetti, Gianluigi Zavattaro. Plan of the. Plan of the Talk. From Choreography to Contracts Contract-based Service Discovery Conclusion.

ian-stanley
Download Presentation

Choreography-driven design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Choreography-driven design Ivan Lanese Department of Computer ScienceUniversity of Bologna INRIA research team FOCUS Joint work with: Mario Bravetti, Gianluigi Zavattaro

  2. Plan of the Plan of the Talk • From Choreography to Contracts • Contract-based Service Discovery • Conclusion

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

  4. WS-CDL • Global view of service interactions Seller Buyer Bank

  5. WS-CDL • Global view of service interactions Seller Request Buyer Bank

  6. WS-CDL • Global view of service interactions Seller Request Offer Buyer PayDescr Bank

  7. WS-CDL • Global view of service interactions Seller Request Offer Buyer PayDescr Payment Bank

  8. WS-CDL • Global view of service interactions Seller Request Offer Buyer PayDescr Confirm Payment Receipt Bank

  9. WS-CDL RequestBuyerSeller ; ( OfferSellerBuyer | PayDescrSellerBank ) ; PaymentBuyerBank ; ( ConfirmBankSeller | ReceiptBankBuyer ) Explicit representation of concurrency

  10. 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)

  11. 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?

  12. A Formal Model for WS-CDL • A global choreography language: H ::= ars | 1 | 0 | H;H | H+H | H|H

  13. A Formal Model for WS-CDL • A global choreography language: H ::= ars | 1 | 0 | H;H | H+H | H|H r invokes the operation a of s Unsuccessful termination Successful termination

  14. A Formal Model for WS-CDL • A global choreography language: H ::= ars | 1 | 0 | H;H | H+H | H|H Sequence Choice Parallel

  15. A Formal Model for orchestrations • A language for orchestrations: P ::= a | ar| 1 | 0 | P;P | P+P | P|P S ::= [P]r | S|S

  16. A Formal Model for orchestrations • A language for orchestrations: P ::= a | ar| 1 | 0 | P;P | P+P | P|P S ::= [P]r | S|S receive on a Unsuccessful termination invoke a at r Successful termination

  17. A Formal Model for orchestrations • A language for orchestrations: P ::= a | ar| 1 | 0 | P;P | P+P | P|P S ::= [P]r | S|S Sequence Choice Parallel

  18. A Formal Model for orchestrations • A language for orchestrations: P ::= a | ar| 1 | 0 | P;P | P+P | P|P S ::= [P]r | S|S Parallel compositionof participants Behaviour of participant r

  19. The “canonical” projection • Projection [[ H ]]t of choreography Hto participant t as if t=r [[ ars ]]t = a if t=s 1 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

  20. Example • Consider the global choreography:ars ; btu • 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

  21. 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, …?

  22. A lattice of possible observation criteria Synchronous Sender Receiver Sender-receiver Disjoint

  23. A lattice of possible observation criteria Assuming synchronous communication: observe either send or receive Synchronous Sender Receiver Sender-receiver Disjoint

  24. A lattice of possible observation criteria Synchronous Assuming asynchronous communication: observe send Sender Receiver Sender-receiver Disjoint

  25. A lattice of possible observation criteria Assuming asynchronous communication: observe receive Synchronous Sender Receiver Sender-receiver Disjoint

  26. A lattice of possible observation criteria Synchronous Sender Receiver Assuming asynchronous communication: observe send and observe receive Sender-receiver Disjoint

  27. A lattice of possible observation criteria Synchronous Sender Receiver Assuming asynchronous communication: observe send and receive together Sender-receiver Disjoint

  28. What about the previous example? • Reconsider the example ars ; bru [ as; bu ]r | [ 1;a ]s | [ 1;b ]u • OK: for synchronous and sender • NO: for receiver, sender-receiver, disjoint

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

  30. 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 (ars + brt ); cst [ ( as+bt );1]r | [ (a+1);ct ]s | [ (1+b);c ]t

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

  32. Example: Receiver equivalence • Global choreography:ars ; bts • Local choreography: [ 1;as ]r | [ a;b ]s | [ 1;bs ]t • The two systems are receiver equivalent

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

  34. Example: Amending choreographies Original choreography: (ars | cru) ; bts Amended choreography: (ars ; h*sz|cru ; i*uz) ;j*zt; bts The two systems are now weak disjoint equivalent Similar patterns for all the criteria

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

  36. Example Consider the global choreography:withdrawcustbank ; paycustshop 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

  37. Example In a receiver connected choreography this will not happenwithdrawcustbank ; notifybankshop ; paycustshop Also in the projection the bank has updated the account before money can be spent

  38. Plan of the From Choreography to Contracts Contract-based service discovery Conclusion Plan of the Talk

  39. Contract:abstract service description Service Contracts • Contract: service “behavioural interface” • correct sequence of invoke and receive • just finite-state labeledtransition system with successful termination public registry

  40. Contract Compliance • Verification of correctness of service composition based on their contracts: successful interaction i.e. no deadlock / termination reached public registry public registry Contract:abstract service description Contract:abstract service description … Reciprocal invocations Service Service …

  41. 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 τ τ √

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

  43. Compliance-Preserving Contract Refinement ! Choreography projection projection compliant by construction Contract Part. 1 Contract Part. n … refines refines compliance preserved by refinement public registry public registry Contract Contract … Reciprocal invocations Service Service …

  44. Contract Refinement Relation Choreography compliant by construction Contract Part. 1 Contract Part. n … refines refines compliance preserved by refinement public registry public registry Contract Contract … Reciprocal invocations Service Service …

  45. Formally: Subcontract Preorder • Preorder ≤ between contracts C: • C’ ≤ C means C’ is a subcontract of C C subcontractpreorder sub-contracts of C

  46. subcontractpreorder sub-contracts of Cn sub-contracts of C1 sub-contracts of C2 … … C’1 C’2 C’n Definition of Preorder Induced from Independent Refinement Given a set of compliant contracts … C1 C2 Cn is a set of compliant contracts

  47. 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 have a + c.0 ≤ a a + c.0 ≤ a • Consequence: no independent refinement!

  48. 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)

  49. Output persistence • Output persistence means that given a process state P: • If P has an output action on a and P-->P’ with a 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 a

  50. Example • Given the choreography: RequestAliceBob; (AcceptBobAlice +RejectBobAlice) The following services can be retrieved: [τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob

More Related