1 / 74

Choreography Projection and Contract Refinement

Choreography Projection and Contract Refinement. Mario Bravetti http://cs.unibo.it/~bravetti. Department of Computer Science University of Bologna INRIA research team FOCUS. Joint work with: Ivan Lanese, Gianluigi Zavattaro. Plan of the. Plan of the Talk. Global and Local Choreography

eden
Télécharger la présentation

Choreography Projection and Contract Refinement

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 Projection and Contract Refinement Mario Bravettihttp://cs.unibo.it/~bravetti Department of Computer ScienceUniversity of Bologna INRIA research team FOCUS Joint work with: Ivan Lanese, Gianluigi Zavattaro

  2. Plan of the Plan of the Talk • Global and Local Choreography • Contract-based service discovery • A dynamic update mechanism • Conclusion

  3. Web Service Choreography Description Language • Describe the interaction among the combined services from a top abstract view Choreography (e.g. WS-CDL) Top abstract view of whole system: each action is a communication involving two of its participants Orchestration (e.g. WS-BPEL) One Party detailed view of the system that orchestrates a part of it by sending (to other parties) & receiving messages

  4. Similar to UML Sequence Diagrams

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

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

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

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

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

  10. WS-CDL RequestBuyerSeller ; ( OfferSellerBuyer | PayDescrSellerBank ) ; PaymentBuyerBank ; ( ConfirmBankSeller | ReceiptBankBuyer )

  11. Projection of the Choreography on the Single Participants Buyer: Invoke(Request)@Seller;Receive(Offer); Invoke(Payment)@Bank;Receive(Receipt) Seller: Receive(Request); (Invoke(Offer)@Buyer | Invoke(PayDescr)@Bank); Receive(Confirm) Bank: Receive(PayDescr);Receive(Payment); (Invoke(Receipt)@Buyer | Invoke(Confirm)@Seller)

  12. Well Formed WS-CDL specifications • Can we always project a WS-CDL specification in an equivalent one? • Which kind of equivalences are preserved?

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

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

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

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

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

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

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

  20. 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[[H*]]t=[[H]]t*

  21. 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 choreographies equivalent? • NO • But, if r=t…. YES[ as; bu ]r | [ a;1 ]s | [ 1;b ]u

  22. Asynchronous communication • Reconsider the example assuming asynchronous communication [ as; bu ]r | [ a ]s | [ b ]u • Communication on a starts before communication on b but could finish after • What we should observe? • Send, Receive, both, …?

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

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

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

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

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

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

  29. Main results • For each observation criterion: • Sufficient conditions(connectedness, unique point of choice, and causality safe) that guarantee that a global choreography is equivalent to the projected one

  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 global and local choreographies? • 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, global sends are abstracted away • weak w.r.t. local send transitions • Sender-Receiver equivalence: both conditions above

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

  33. Plan of the Plan of the Talk • Global and Local Choreography • Contract-based service discovery • A dynamic update mechanism • Conclusion

  34. Contract:abstract service description Service Contracts • Contract: service “behavioural interface” • correct sequences of invoke and receive • as in an orchestration(role of a coreography) • just finite-state labeledtransition systems with successful termination public registry

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

  36. Service Compliance: Formally • Services are compliant if the following holds for their composition P: P --->* P’implies that there exist P’’ and P’’’ s.t. P’ --->* P’’ ---> P’’’ • i.e. every computation can be extended to reach successful completion of all services • termination under fairness assumption τ τ √

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

  38. 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 …

  39. First Relation: Contract Refinement 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 …

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

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

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

  43. Maximal pre-order • It exists changing some assumptions: • Limiting the considered services (output persistence) • Strengthening the notion of compliance (strong compliance) • Moving to asynchronous communication(e.g. via message queues)

  44. 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 • Outputs cannot resolve the pick operator for external choices (the decision to execute outputs is taken internally) a

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

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

  47. Example • Given the choreography: RequestAliceBob; (AcceptBobAlice +RejectBobAlice) 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

  48. “Standard” Contract Compliance • Example: • S1: invoke(a);invoke(b) • S2: receive(a);invoke(c) • S3: receive(c);receive(b) S1 S2 S3

  49. “Standard” Contract Compliance • Example: • S1: invoke(a);invoke(b) • S2: receive(a);invoke(c) • S3: receive(c);receive(b) S1 S2 S3

  50. “Standard” Contract Compliance • Example: • S1: invoke(a);invoke(b) • S2: receive(a);invoke(c) • S3: receive(c);receive(b) S1 S2 S3

More Related