1 programming sagas in sock ivan lanese computer science department university of bologna italy...

Download 1 Programming SAGAs in SOCK Ivan Lanese Computer Science Department University of Bologna Italy Joint work with Gianluigi Zavattaro The SOCK saga

Post on 21-Dec-2015

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Slide 1
  • 1 Programming SAGAs in SOCK Ivan Lanese Computer Science Department University of Bologna Italy Joint work with Gianluigi Zavattaro The SOCK saga
  • Slide 2
  • The saga l The world: faults and compensations in SOC l The weapon: SOCK l The treasure: SAGAs l The quest: a mapping l The way back: dynamic SAGAs l Conclusion: and all the activities were compensated
  • Slide 3
  • The saga l The world: faults and compensations in SOC l The weapon: SOCK l The treasure: SAGAs l The quest: a mapping l The way back: dynamic SAGAs l Conclusion: and all the activities were compensated
  • Slide 4
  • Service oriented computing (SOC) l A world where applications are programmed by composing entities called services Distributed over the network Autonomous and heterogeneous (loosely coupled) Dynamically searched according to their properties and composed l All managed by standards for interoperability (SOAP, WSDL, UDDI, BPEL, ) l Upon composition services interact via message passing according to WSDL operations One-way for invoking a service Request-response for invoking a service and waiting for the response
  • Slide 5
  • Service oriented computing and faults l Safe composition of services requires to deal with faults No guarentee on components behaviour because of loose coupling Only what published in the interfaces can be assumed Disconnections, message losses, l A fault is an abnormal situation that forbids the continuation of an activity l Approaches based on long running transactions and compensations l A long running transaction cannot backtrack in case of failure (differently from ACID transactions) Impossible to lock resources for long times, irreversible actions l A compensation is executed to take the system to a consistent state
  • Slide 6
  • Long running transactions l Different mechanisms are commonly used for defining long running transactions l For instance, BPEL exploits Fault handlers: specify how to recover from a fault Termination handlers: specify how to terminate an ongoing activity when reached by a fault from a parallel activity Compensation handlers: specify how to compensate a successfully terminated activity if requested for fault recovery
  • Slide 7
  • Formal models for long running transactions l Different formal models have been proposed to analyze long running transactions Interaction based compensations, extending name passing calculi such as pi-calculus with operators for error handling Compensable flow composition, analyzing how compensations of simple activities are composed l We compare two models, one for each approach SOCK for interaction based compensations SAGAs calculi for compensable flow composition models
  • Slide 8
  • The saga l The world: faults and compensations in SOC l The weapon: SOCK l The treasure: SAGAs l The quest: a mapping l The way back: dynamic SAGAs l Conclusion: and all the activities were compensated
  • Slide 9
  • SOCK (Service Oriented Computing Kernel) l A calculus for modelling service oriented systems l Strongly inspired by current technologies WSDL, WS-BPEL Implemented by Jolie l but featuring a formal LTS semantics l SOCK has three layers: behaviour, engine and system l Faults are managed at behaviour layer
  • Slide 10
  • Behaviour primitives o r @ z ( ~ y ; ~ x ) o ( ~ x ) o r ( ~ x ; ~ y ; P ) OutputInput One-way Request-response o @ z ( ~ y ) and assignment x: = e
  • Slide 11
  • Behaviour composition operators P ; Q ? P : Q w h i l e d o P P j Q From sequential languages From concurrent calculi P i 2 W i ; P i
  • Slide 12
  • Fault handling in SOCK l Fault handling exploits fault/termination/compensation handlers as in BPEL l but handlers can be installed and updated dynamically l At runtime the scope will also contain the active handlers: {P;H} q P :: = ::: S t an d ar d opera t ors f P g q S cope t h row ( f ) T h rowa f au l t i ns t ( H ) I ns t a llh an dl er comp ( q ) C ompensa t eascope
  • Slide 13
  • The scope hierarchy P H q P H q P H q P H q P H q
  • Slide 14
  • Throwing a fault q1q1 q2q2 (f,Q) Throw (f) (q 2,T 2 ) (q 1,T 1 ) A fault f is raised by Throw(f)
  • Slide 15
  • Throwing a fault q1q1 q2q2 (f,Q) (q 2,T 2 ) (q 1,T 1 ) f It propagates upward and kills the traversed activities
  • Slide 16
  • Throwing a fault T1T1 q1q1 T2T2 q2q2 (f,Q) f Termination handlers of parallel activities are executed
  • Slide 17
  • Throwing a fault T1T1 q1q1 T2T2 q2q2 Q f The fault handler for f is executed
  • Slide 18
  • Dynamic installation of handlers l New handlers update the old ones l Allowed for fault and termination handlers l Allows to keep the handler up-to-date as far as the activity progresses l Handler update has priority on other operations It is never the case that the state has changed and the corresponding handler update has not been performed
  • Slide 19
  • Installing a fault/termination handler Inst (f,Q)
  • Slide 20
  • Installing a fault/termination handler (f,Q)
  • Slide 21
  • Compensation handlers l Allow to undo the effect of a successfully terminated activity l Are the last available termination handlers l Should be activated explicitly by comp(q) l Do nothing if the activity to be compensated has not terminated with success
  • Slide 22
  • Installing compensation handlers q qq Inst (q,Q)
  • Slide 23
  • Installing compensation handlers q (q,Q) q terminates qq
  • Slide 24
  • Installing compensation handlers (q,Q) Handlers in q can compensate q using comp(q) qq
  • Slide 25
  • Faults and request-responses l We dont want faults to spoil the request-response communication pattern Faults may happen both at client and service side l A fault at the service side may cause no response message l A fault at the client side may cause the client not to wait for the answer
  • Slide 26
  • Our approach l At the service side, a running request-response reached by a fault sends a fault notification as answer The fault is notified to the client side, and the client can perform local recovery actions l A client always waits for the reply, even if reached by a local fault l Furthermore, in case of successful response the receive operation can update handlers to match the state change o r (y,x, H ) installs handlers in H only if a successful answer is received
  • Slide 27
  • The saga l The world: faults and compensations in SOC l The weapon: SOCK l The treasure: SAGAs l The quest: a mapping l The way back: dynamic SAGAs l Conclusion: and all the activities were compensated
  • Slide 28
  • SAGAs calculi l A language for modelling compensable transactions l Proposed by Bruni, Montanari, Melgratti [POPL05] l The basic building blocks are compensable actions A%B l That can be composed in sequence and parallel to build a SAGA l Allows to model long running transactions at the high level of abstraction l Different possible semantics l We consider the semantics with interruption and centralized compensation
  • Slide 29
  • SAGAs semantics l SAGAs are equipped with a labelled big-step semantics l The final result of a SAGA can be : success : abort, if the forward flow aborts but the compensation succeeds : failure, if both the forward flow and the compensation abort l Labels of the big-steps contain the names of activities completed with success
  • Slide 30
  • Atomic compensable activity A%B l Succeeds if A succeeds A as label Compensation B is installed l Aborts if A aborts Empty label No compensation is installed
  • Slide 31
  • Sequential composition P;P l Succeeds if P and P succeed The observation is the sequential composition of observations l Aborts if P aborts l If P succeeds and P aborts, P should be compensated If the compensation of P succeeds then P;P aborts If the compensation of P aborts then P;P fails Sequential activities are compensated in reverse order
  • Slide 32
  • Parallel composition P|P l Succeeds if both P and P succeed The observation is the parallel composition of the observations l Does not succeed if any activity aborts The other is stopped (interruption) The activities executed so far are compensated (centralized compensation) If the compensation succeeds then P|P aborts If the compensation aborts then P|P fails l Parallel activities are compensated in parallel
  • Slide 33
  • The saga l The world: faults and compensations in SOC l The weapon: SOCK l The treasure: SAGAs l The quest: a mapping l The way back: dynamic SAGAs l Conclusion: and all the activities were compensated
  • Slide 34
  • Why a mapping? l SAGAs are at the high level of abstraction Good for fast modelling and proving properties l SOCK is at the low level of abstraction Implemented by Jolie l We want to pass automatically from the SAGA specification to the SOCK implementation l Extract skeletons of SOCK programs defining error handling from SAGAs
  • Slide 35
  • Idea of the mapping l Activities are implemented by remote services An operation A r for each activity A l If the activity succeeds, the service sends back a normal answer l If the activity aborts, the service sen