Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards Dynamic Updates in Service Composition - Prof. Mario Bravetti

141 views

Published on

We present adaptable processes as a way of overcoming the limitations that process calculi have for describing patterns of dynamic process evolution. Such patterns rely on direct ways of controlling the behavior and location of running processes, and so they are at the heart of the adaptation capabilities present in many modern concurrent systems. Adaptable processes have named scopes and are sensible to actions of dynamic update at runtime; this allows us to express dynamic and static topologies of adaptable processes as well as different evolvability patterns for concurrent processes. We then consider distributed adaptability, where a process can update part of a protocol by performing dynamic distributed updates over a set of protocol participants. Dynamic updates in this context are presented as an extension of our work on choreographies and behavioural contracts in multiparty interactions. We show how update mechanisms considered for adaptable processes can be used to extend the theory of choreography and orchestration/contracts, allowing them to be modified at run-time by internal (self-
adaptation) or external intervention.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Towards Dynamic Updates in Service Composition - Prof. Mario Bravetti

  1. 1. Mario Bravetti Department of Computer Science University of Bologna INRIA research team FOCUS Towards Dynamic Updates in Service Composition Joint work with: Gianluigi Zavattaro
  2. 2. Plan of the Choreographies and Orchestrations Contract-based service discovery A dynamic update mechanism Conclusion Plan of the Talk
  3. 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. 4. Similar to UML Sequence Diagrams
  5. 5. WS-CDL Global view of service interactions Buyer Seller Bank
  6. 6. WS-CDL Global view of service interactions Buyer Seller Request Bank
  7. 7. WS-CDL Global view of service interactions Buyer Seller PayDescr Request Offer Bank
  8. 8. WS-CDL Global view of service interactions Buyer Seller PayDescr Request Offer Bank Payment
  9. 9. WS-CDL Global view of service interactions Buyer Seller PayDescr Request Offer Bank Payment Confirm Receipt
  10. 10. WS-CDL RequestBuyer Seller ; ( OfferSeller Buyer | PayDescrSeller Bank ) ; PaymentBuyer Bank ; ( ConfirmBank Seller | ReceiptBank Buyer )
  11. 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. 12. Behavioural contracts and service retrieval Problem of retrieving in the internet services (by behavioral contracts) that: interact without blocking (compliant) can play the roles described by the choreography Useful notion: projection of choreography into contracts (one for each role) We cannot require that exactly projected contracts are retrieved
  13. 13. … Contract: abstract service description Contract: abstract service description Participant 1 Participant n Deriving Set of Compliant Contracts from Choreography [CHY07][BZ07b] compliant by construction Choreography: abstract description of the composition of a group of collaborating services e.g. WS-CDL projection projection
  14. 14. … 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
  15. 15. A Formal Model for WS-CDL A global choreography language: H ::= ar s | 1 | 0 | H;H | H+H | H|H | H*
  16. 16. 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 Successful termination Unsuccessful termination
  17. 17. A Formal Model for WS-CDL A global choreography language: H ::= ar s | 1 | 0 | H;H | H+H | H|H | H* Choice Sequence Parallel Repetition
  18. 18. Standard semantics Standard semantics where: ar s produces a ar s transition to 1 1 produces a √ transition to 0
  19. 19. Semantics of choreographies
  20. 20. A Formal Model for orchestrations A language for orchestrations: C ::= a | ar | τ | 1 | 0 | C;C | C+C | C|C | C* P ::= [C]r | P|P
  21. 21. A Formal Model for orchestrations A language for orchestrations: C ::= a | ar | τ | 1 | 0 | C;C | C+C | C|C | C* P ::= [C]r | P|P receive on a Successful termination Unsuccessful termination invoke a at r internal
  22. 22. A language for orchestrations: C ::= a | ar | τ | 1 | 0 | C;C | C+C | C|C | C* P ::= [C]r | P|P A Formal Model for orchestrations Choice Sequence Parallel Repetition
  23. 23. A Formal Model for orchestrations A language for orchestrations: C ::= a | ar | τ | 1 | 0 | C;C | C+C | C|C | C* P ::= [C]r | P|P Behaviour of participant r Parallel composition of participants
  24. 24. Standard semantics Standard semantics where: as transition of role r synchronizes with a transition of role s and produces a ar s transition 1 produces a √ transition to 0 √ is synchronized over parallel
  25. 25. Notion of Implementation Given a choreography H, a system P implements H if: P is a composition of compliant contracts Intuitively they all always reach termination √ (we will see) Each completed (√ terminating) weak (τ abstracting) trace of P is a completed trace of H all computations of P are correct conversations according to the choreography H
  26. 26. Examples of choreography Implementations: Given the choreography: RequestAlice Bob; (AcceptBob Alice + RejectBob Alice) The following are implementations: [RequestBob;(Accept+Reject)]Alice | [Request;(AcceptAlice+RejectAlice)]Bob
  27. 27. Examples of choreography Implementations: Given the choreography: RequestAlice Bob; (AcceptBob Alice + RejectBob Alice) The following are implementations: [RequestBob;(Accept+Reject)]Alice | [Request;(AcceptAlice+RejectAlice)]Bob [RequestBob;(Accept+Reject+Retry)]Alice | [Request;(AcceptAlice+RejectAlice)]Bob
  28. 28. Examples of choreography Implementations: Given the choreography: RequestAlice Bob; (AcceptBob Alice + RejectBob Alice) The following are implementations: [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
  29. 29. “Canonical” Projection and Well-formed Choreography [SC 2007] Canonical projection [[ ]]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* H is well-formed if the system P, achieved via canonical projections, implements H
  30. 30. Example Consider the choreography H: ar s ; bt u Projection: [ as ;1]r | [ a;1 ]s | [ 1;bu ]t | [ 1;b ]u Is H well-formed? NO But, if r=t…. YES [ as; bu ]r | [ a;1 ]s | [ 1;b ]u
  31. 31. Connected Choreography (with Ivan Lanese) Sufficient conditions unique point of choice, connectedness of sequence, causality safety that guarantee that H is well-formed i.e. projection of a connected choreography H produces an implementation of H
  32. 32. 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 ); c s t [ ( as+bt );1]r | [ (a+1);ct ]s | [ (1+b);c ]t
  33. 33. Plan of the Choreographies and Orchestrations Contract-based service discovery A dynamic update mechanism Conclusion Plan of the Talk
  34. 34. Contracts Contract: service “behavioural interface” correct sequences of invoke and receive as in an orchestration (role of a coreography) just finite-state labeled transition systems with successful termination Contract: abstract service description Service public registry
  35. 35. 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
  36. 36. Service Compliance: Formally Services are compliant if the following holds for their composition P: P ---> … ---> P’ implies that there exists P’’ s.t. P’ ---> … ---> P’’ ---> i.e. every computation can be extended to reach successful completion of all services termination under fairness assumption αααα1111 √ ααααn αααα1111 ααααm
  37. 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. 38. … 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
  39. 39. … 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
  40. 40. Formally: Subcontract Preorder C sub-contracts of C subcontract preorder Preorder ≤ between contracts C: C’ ≤ C means C’ is a subcontract of C
  41. 41. Definition of Preorder Induced from Independent Refinement C1 C2 Cn Given a set of compliant contracts is a set of compliant contracts subcontract preorder sub-contracts of C2 … sub-contracts of C1 sub-contracts of Cn C’1 C’2 C’n … …
  42. 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. 43. Maximal pre-order It exists changing some assumptions (asymmetry between inputs and outputs) Constraining the structure of contracts: outputs choosen internally (output persistence) Strengthening the notion of compliance: when an output is performed a corresponding input is required to be already enabled, like in ready-send of MPI (strong compliance) Moving to asynchronous communication (e.g. via message queues)
  44. 44. Output persistence Output persistence means that given a process state P: If P has an output transition on a and P-->P’ with αααα different from output on a, then also P’ has an output transition on a (and P' --> ) αααα √ a a b √√√√
  45. 45. Syntactically… (guarantees output persistance) This holds, for instance, in WS-BPEL Outputs cannot resolve the pick operator for external choices (the decision to execute outputs is taken internally) External choice among inputs: a + b but a + b τ;a + τ;b a + b a + τ;b no external choice among outputs (and mixed choice) in contracts!
  46. 46. Choreography implementations (with output persistent contracts) Projection modified: [[ ar s ]]t = τ;as if t=r RequestAlice Bob; (AcceptBob Alice + RejectBob Alice) The following services can be retrieved: [τ;RequestBob;(Accept+Reject)]Alice | [Request;(τ;AcceptAlice+τ;RejectAlice)]Bob
  47. 47. Choreography implementations (with output persistent contracts) Projection modified: [[ ar s ]]t = τ;as if t=r 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
  48. 48. Choreography implementations (with output persistent contracts) Projection modified: [[ ar s ]]t = τ;as if t=r 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
  49. 49. C’ ≤ C iff for every context P [C]|P compliance implies [C’]|P compliance ≤max is a subcontract preoder ≤max includes all subcontract preorders With respect to (fair) testing not only the test P has to succeed but also the tested C Compliance testing is the maximal preorder max
  50. 50. Properties of the maximal subcontract preorder If we assume outputs al to be directed to a location l (e.g. role of a choreography) we can reduce the problem: C’ ≤max C iff C’N-I(C) ≤ max C i.e. to subcontract relation when inputs not among inputs of C I(C) are restricted because compliant tests of C cannot perform reachable outputs to C that it cannot receive
  51. 51. Thus… (typical in session types) External choices on inputs can be extended: a+b ≤max a (thanks to this property) Internal choices on outputs can be reduced: ττττ.al ≤max ττττ;al + ττττ;bl' (being more deterministic, as in testing)
  52. 52. Input and Output knowledge Contracts with undirected outputs à la CCS property does not hold, e.g. a+b ≤max a Consider for instance (capturing) the correct system [ a ] | [ττττ; a .b] | [ττττ;b ] and the incorrect one [ a+b ] | [ττττ; a .b] | [ττττ;b ] Problem can be solved by considering knowledge of I/O of other contracts ≤I,O exploiting knowledge we have a+b ≤N,N-{b} a
  53. 53. Subcontract relation contains a universal quantification over possible contexts Sound characterization resorting to a must-testing theory (should-testing [RV05]) C’ ≤ C is implied by C’ N-I(C) ≤should-testing C i.e. ≤ max coarser than testing preorder (and of simulation) Decidible Sound Characterization Based on a Must-like Testing max
  54. 54. Uncontrollable contracts Trace equivalence not coarser than ≤max because contracts can include traces not leading to success Those traces not observed by tests Example: uncontrollable contracts (unsuccesful for any test) are all equivalent: a;b;0 equivalent to b;c;0
  55. 55. is conformant for participant 1 to is conformant for participant n to … Choreography Choreography Conformance Contract public registry Contract public registry Service Service… Reciprocal invocations compliance guaranteed by conformance
  56. 56. Definition of Relation Induced from Independence Property Hwith roles p1,p2,…,pn [C1]p1 | [C2]p2 … | [Cn]pn implements H … … contracts for p1 contracts for p2 contracts for pn conformance relation
  57. 57. No Maximal Choreography Conformance Relation Consider the choreography ar s | br s that can be implemented as: [ τ;as | τ;bs ]r | [ τ;a;b + τ;b;a ]s [τ;as;τ;bs + τ;bs;τ;as ]r | [a|b]s but not as: [τ;as;τ;bs + τ;bs;τ;as ]r | [ τ;a;b + τ;b;a ]s Notice that we used output persistent contracts, so even asymmetry of I/O does not help
  58. 58. Summary of Results Refinement with knowledge about other initial contracts limited to I/O actions “normal” compliance: Uncostrained contracts: maximal relation does not exist Contracts where outputs are internally chosen (output persistence): maximal relation exists and “I” knowledge is irrelevant Output persistent contracts where outputs are directed to a location: maximal relation exists and “I/O” knowledge is irrelevant strong compliance: Uncostrained contracts (where output are directed to a location): maximal relation exists and “I/O” knowledge is irrelevant queue-based (asynchronous) compliance: Uncostrained contracts (where output are directed to a location): maximal relation exists and “I/O” knowledge is irrelevant
  59. 59. 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 Much coarser: all non-controllable systems are equivalent 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)
  60. 60. Plan of the Choreographies and Orchestrations Contract-based service discovery A dynamic update mechanism Conclusion Plan of the Talk
  61. 61. Updatable processes/contracts (with Marco Carbone) How to model updatable processes? Eg. services which receive workflow from the environment in order to interact with it internal “adaptable/mutable” subparts of cloud behaviour By extending choreographies and orchestrations/contracts with updatable parts (named scopes) X[H] and update actions/primitives X{H}
  62. 62. Buyer-Seller-Bank Example Consider the running system: [X[CmcBuyer]| C]buyer | [C']seller | [X[CmcBank]|C'']bank if the following update is performed: X{buyer:CvisaBuyer, bank:CvisaBank} the system becomes: [X[CvisaBuyer]| C]buyer | [C']seller | [X[CvisaBank]|C'']bank
  63. 63. Updating a scope, graphically X X→ X
  64. 64. Updating a scope, graphically X X→ X proj
  65. 65. Updating a scope, graphically X X→ X X→ proj proj
  66. 66. Updating a scope, graphically X X→ X X→ proj projproj
  67. 67. Dynamic Choreographies Each scope X associated to a set of roles given function type(X) = {r1,…,rn} Global choreography language: H ::= ar s | 1 | 0 | H;H | H+H | H|H | H* | X[H] | Xr{H} with roles(H) included in type(X)
  68. 68. Extending choreography semantics with scope and updates where H[H'/X] turns scopes X[H''], for any H'', occurring inside H into X[H']
  69. 69. Dynamic Orchestrations A language for orchestrations: C ::= a | ar | 1 | 0 | C;C | C+C | C|C | C* | X[C] | X{r1:C1, …, rn:Cn} P ::= [C]r | P|P A distributed update can be performed if no scope X[C] of roles in type(X) has started
  70. 70. Standard “canonical” projection [Bravetti, Zavattaro SC 2007] Projection [[ H ]]t of choreography H to 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*
  71. 71. Extended…. Projection [[ H ]]t of choreography H to participant t X[ [[H]]t ] if t in type(X) [[ X[H] ]]t = 1 otherwise X{t1:[[H]]t1, …, tn:[[H]]tn } if t = r [[ Xr{H} ]]t = 1 otherwise where type(X) = {t1,…,tn}
  72. 72. Extension of Connectedness and external updates Constraint: there are not (and cannot be produced) scopes in parallel with the same name X so not to confuse starts of different scopes Open transitions: update choreographies H in a scope X from "outside" provided: H is connected The update does not violate the constraint above
  73. 73. Main Theorem Projection of a connected choreography H produces an implementation of H Traces considered by implementation definition also include open transitions
  74. 74. Channels "a" statically associated to choreographies H (global type) Typing a concrete langauge with sessions (session types)
  75. 75. Networks and Expressions
  76. 76. Session Typing is not trivial Γ typing environment each channel is typed with a choreography ∆ maps: each started session into an orchestration
  77. 77. Typing scopes and updates Inside a scope X[] we may communicate using several started sessions We must update all session (types) the process in the scope is engaged in Updates are going to update code inside multiple sessions must be allowed individually by their types
  78. 78. An idea of the typing rules
  79. 79. Example with two channels
  80. 80. Typing the example
  81. 81. Plan of the Choreographies and Orchestrations Contract-based service discovery A dynamic update mechanism Conclusion Plan of the Talk
  82. 82. Conclusion We are working on: Use of the above in the context of session types for typing a concrete language: typing rules and properties (e.g. subject reduction)
  83. 83. Conclusion Open problems: Complete characterization of compliance testing work in this direction has been done in [Bernardi, Hennessy Concur 2013] where however uncontrollable processes are not characterized and fairness is not considered Refinement theory for dynamic (with updates) choreographies/contracts
  84. 84. 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 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 '09, LNCS 5569 M. Bravetti, C. Di Giusto, J. A. Pérez, and G. Zavattaro. A Calculus for Component Evolvability (Extended Abstract). In FACS’10 M. Bravetti, C. Di Giusto, J. A. Pérez, and G. Zavattaro. Adaptable Processes (Extended Abstract). In FORTE/FMOODS’11 M. Boreale, M. Bravetti. Advanced Mechanisms for Service Composition, Query and Discovery in Rigorous Software Eng. for Service-Oriented Systems '11, LNCS 6582 M. Bravetti, M. Carbone, T. Hildebrandt, I. Lanese, J. Mauro, J. A. Pérez, G. Zavattaro: Towards Global and Local Types for Adaptation. In BEAT2 '13, LNCS 8368

×