Compensations in Orchestration Languages

Size: px

Start display at page:

Download "Compensations in Orchestration Languages"

Hubert Greene
5 years ago
Views:

1 Compensations in Orchestration Languages Retry Limit Exceeded Notify Customer Invalid CC Booking Booking Book Flight Get Credit Card Information Cancel Flight Charge Credit Card Book Hotel Cancel Hotel Update Credit Card Information Update Credit Card Info Handle Compensation Booking Flight Hotel Update Customer Record Handle Booking Error Flight Booking Error 2 Retry Limit Exceeded Notify Customer Failed Booking Booking Error 1 Booking Error 2 Hotel Gianluigi Zavattaro Joint work with C. Guidi, I. Lanese, F. Montesi Joint FOCUS Research Team INRIA / University of Bologna

2 Plan of the Talk u Long-Running Transactions (LRTs) [NestedSagas] u A renewed interest in LRTs [BPMN,WS-BPEL] u The JOLIE orchestration language u Dynamic compensations in JOLIE

3 Plan of the Talk u Long-Running Transactions (LRTs) [NestedSagas] u A renewed interest in LRTs [BPMN,WS-BPEL] u The JOLIE orchestration language u Dynamic compensations in JOLIE

4 Data Processing Application: an example billing phone call enter order shipping inventory u Purchase order n A transaction composed of sub-transactions

5 A First Solution u Use of nested (standard) transactions u Standard transactions are ACID n A = atomic (all or nothing) n C = consistent (w.r.t. the application logic) n I = isolated (unobservable) n D = durable (persistent) u ACIDity implies a perfect roll-back u Not satisfactory n The whole transaction may require a long period: resources may be locked for the whole transaction

6 Nested Sagas (1) compensation compensation billing trigger phone call enter order compensation shipping inventory u Compensations are provided n No perfect roll-back n No isolation

7 Nested Sagas (2) compensation compensation billing trigger phone call enter order compensation enter order inventory u Sagas can be nested

8 Nested Sagas (3) compensation compensation billing trigger phone call enter order compensation enter order monitor inventory u An exception handler can be associated to each Saga

9 Plan of the Talk u Long-Running Transactions (LRTs) [NestedSagas] u A renewed interest in LRTs [BPMN,WS-BPEL] u The JOLIE orchestration language u Dynamic compensations in JOLIE

10 Internet Technologies XML TCP/IP Connectivity HTML Presentation Programmability Web Pages Browse the Web Program the Web

11 Web Service Orchestration u WS-BPEL [OASIS standard]: Language for Web Service Orchestration n Description of the message exchanged among Web Services that cooperate in a business process u BPMN [OMG standard]: n Graphical notation for business procedures

12 BPMN: Business Process Modeling Notation u Selection of a Nobel Prize laureate I47M8<!N(((!68F6;-;6785O?78>6<18;6-0!87.68-;678!>74.5! -41!518;!;7!5101?;1<!%7.68-;745 L1/74;!S6;T! L1?7..18<-;6785 %7)10!:7..6;;11!>74!$1<6?681!@1/;1.)14 A1-4! 8B9 %7.68-;678! =74. :7001?;! :7./01;1<! =74.5 :7./01;1<! # *! :-8<6<-;15 %7.68-;678! C8F6;-;678 %7.68-;678!=74. R1;14.681! %11<!>74! +,/14;! I5565;-8?1 # *! :-8<6<-;15 %7 A15 +,/14;! # *! :-8<6<-;15 H65;!7>!:-8<6<-;15! ;7!)1!I551551< :7001?;! :-8<6<-;15!J74K! I ; L1/74;5 :-8<6<-;15! -8<!;T164!S74K5 :-8<6<-;15! I ;5 J46;1! L1?7..18<-;6785! L1?7..18<-;6785 L1/74;!S6;T! L1?7..18<-;6785 U70<!%7)10! #46V1!IS-4<! :141.78* %7.68-;74 C<18;6>*! #7;18;6-0! :7./01;1<! =74.D5E %7.68-;678! =74.D5E!@18; +,/14; I55155! :-8<6<-;15! I ;! L1/74; I ;5! :7./01;1< %7)10!I551.)0* R65?M55! %7.68-;6785 H-M41-;15 D$11;68W!&E I887M8?1! %7)10!#46V1! H-M41-;15 I887M8?1.18;! $-<1 %7.68-;74!.-*!87.68-;1! 781!74!.741!% I!5101?;1<!+,/14;!65!-5K1<!;7! !;T1!S74K!7>!;T1! # *!:-8<6<-;15!68!;T1! 065; %7)10!#46V1!H-M41-;1 I887M8?1.18;

13 BPMN: Long Running Transactions u An activity can have a corresponding compensation activity u This is triggered by a compensate event

14 BPMN: Long Running Transactions Booking u Also user defined compensation handlers can be programmed Book Flight Book Hotel Cancel Flight Cancel Hotel Handle Com pens ation Booking Flight Hotel Update Customer Record

15 LRTs in WS-BPEL <scope name="mainscope"> <faulthandlers> <catchall> <compensatescope target="invoicesubmissionscope" /> </catchall> </faulthandlers> <sequence>... <scope name="invoicesubmissionscope">... <compensationhandler> <invoke name="withdrawinvoicesubmission"... /> </compensationhandler> <invoke name="submitinvoice"... /> </scope>...   </sequence> </scope>

16 Plan of the Talk u Long-Running Transactions (LRTs) [NestedSagas] u A renewed interest in LRTs [BPMN,WS-BPEL] u The JOLIE orchestration language u Dynamic compensations in JOLIE

17 JOLIE: programming orchestrators with a C / Java like syntax execution { concurrent cset { request.id interface myinterface { OneWay: login RequestResponse: get_data inputport myport { Protocol: http Location: socket://localhost:2000 Interfaces: myinterface main { login( request ) ; get_data( request )( response ) { response.data = your data + request.id

18 JOLIE: basic communication primitives Data are exchanged by means of operations Two types of operations: One-Way: receives a message; Request-Response: receives a message and sends a response to the caller. A: B: main { sendnumber@b( 5 ) main { sendnumber( x ) A sends 5 to B through the sendnumber operation.

19 JOLIE: basic communication primitives Data are exchanged by means of operations Two types of operations: One-Way: receives a message; Request-Response: receives a message and sends a response to the caller. A: B: main { twice@b( 5 )( x ) A sends 5 to B; B doubles the received value; B sends the result back to A. main { twice( x )( result ) { result = x * 2

20 JOLIE: communication ports A should know how to contact B B should expose the operation twice Two types of ports: Input ports: expose operations Output ports: bind output operations to input operations A: B: main { twice@b( 5 )( x ) main { twice( x )( result ) {result = x * 2

21 JOLIE: communication ports A should know how to contact B B should expose the operation twice Two types of ports: Input ports: expose operations Output ports: bind output operations to input operations A: inputport MyInput { Location: socket://localhost:8000/ Protocol: soap RequestResponse: twice(int)(int) Location Protocol Interface main { twice@b( 5 )( x ) main { twice( x )( result ) {result = x * 2

22 JOLIE: communication ports A should know how to contact B B should expose the operation twice Two types of ports: Input ports: expose operations Output ports: bind output operations to input operations outputport B { Location: socket:// :8000/ Protocol: soap RequestResponse: twice(int)(int) inputport MyInput { Location: socket://localhost:8000/ Protocol: soap RequestResponse: twice(int)(int) Location Protocol Interface main { twice@b( 5 )( x ) main { twice( x )( result ) {result = x * 2

23 JOLIE: work- and control-flow Basic activities can be combined with sequence, parallel and choice constructs sequence: parallel: choice: x ) ; receive( msg ) send@s( x ) receive( msg ) [ recv1( x ) ] { [ recv2( x ) ] { as well as the usual control flow constructs if then else: for: if ( x > 1 ) { else { for( i = 0, i < n, i++ ) { while: while( i < 0 ) {

24 Plan of the Talk u Long-Running Transactions (LRTs) [NestedSagas] u A renewed interest in LRTs [BPMN,WS-BPEL] u The JOLIE orchestration language u Dynamic compensations in JOLIE

25 Statically Defined Hierarchy of Scopes main { scope(carrepair){ { scope(carrental){... scope(garage){... ; scope(towingtrack){... carrepair carrental garage towingtrack

26 Fault handling main { scope(carrepair){ { scope(carrental){... scope(garage){... ; scope(towingtrack){... throw(notowtrack); carrepair carrental garage towingtrack

27 Fault handling l Scopes have a name q, an activity P, and a set of fault handlers H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler l While going up, parallel scopes are interrupted P H q

28 Fault handling q l Scopes have a name q, an activity P, and a set of fault handlers H P H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler P H q P H q l While going up, parallel scopes are interrupted q q P H P H

29 Fault handling l Scopes have a name q, an activity P, and a set of fault handlers H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler l While going up, parallel scopes are interrupted (f,q) q 1 (q 1,T 1 ) q 2 throw(f) (q 2,T 2 )

30 Fault handling l Scopes have a name q, an activity P, and a set of fault handlers H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler l While going up, parallel scopes are interrupted (f,q) q 1 (q 1,T 1 ) q 2 throw(f) (q 2,T 2 )

31 Fault handling l Scopes have a name q, an activity P, and a set of fault handlers H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler l While going up, parallel scopes are interrupted (f,q) q 1 (q 1,T 1 ) q 2 throw(f) (q 2,T 2 ) T 2

32 Fault handling l Scopes have a name q, an activity P, and a set of fault handlers H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler l While going up, parallel scopes are interrupted (f,q) T 1 q 1 (q 1,T 1 ) q 2 throw(f) (q 2,T 2 ) T 2

33 Fault handling l Scopes have a name q, an activity P, and a set of fault handlers H l They are organized in a hierarchy l When a fault is raised, it goes up in the hierarchy until it reaches a handler l While going up, parallel scopes are interrupted Q (f,q) T 1 q 1 (q 1,T 1 ) q 2 throw(f) (q 2,T 2 ) T 2

34 Dynamic fault handling u In Nested SAGAS, WS-BPEL, BPMN, etc. the fault handlers are statically defined u In JOLIE fault handlers can be dynamically modified n We use an installation primitive that explicitly installs the handlers n The new handlers can be defined as modifications of the previous ones

35 Dynamic installation of handlers q q inst(f,q) (f,q) inst(f,r;ch) q (f,q) q (f,r;q)

36 Example u Consider: {throw(f) while (i <100) if i%2=0 then P else Q, H q u When f is thrown, execute P and Q to undo the instances of P and Q in the order in which they have been executed { throw(f) while (i <100) if i%2=0 then P;inst(cH;P ) else Q;inst(cH;Q ), H q

37 Compensation handler u When a scope terminates, its last termination handler becomes its compensation handler q q (q,q) q successfully terminates q (q,q) Handlers in q activates Q performing comp(q)

38 Example u Reserve a hotel and a public transportation n Take the train, or in case of failure (notified with ft ) take a bus { inst([ft Bus; inst([q ch; revbus])]); Hotel; inst([q revhotel]); Train; inst([q ch; revtrain]) q

39 Faults and Request-responses u The JOLIE fault handling mechanism does not spoil request-responses u In this way non-trivial distributed fault handling policies can be programmed

40 Faults on server side u A client asks a payment to the bank, the bank fails u In ActiveBPEL (a largely used BPEL engine) the client receives a generic missing-reply exception u Our approach n The exact fault is notified to the client n The notification acts as a fault for the client n Suitable actions can be taken to manage the remote fault

41 Faults on client side u A client asks a payment to the bank, then fails before the answer u In BPEL the return message is discarded u Our approach n The return message is waited for n The handlers can be updated according to whether or not a non-faulty message is received n The remote activity can be compensated if necessary

42 Conclusion and Future work. u We have seen some model for compensation u Future work: n How to combine reversibility and compensation?...

Fault in the Future. Ivan Lanese Computer Science Department University of Bologna/INRIA Italy

Fault in the Future. Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Fault in the Future Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Joint work with Gianluigi Zavattaro and Einar Broch Johnsen From COORDINATION 2011 Error handling Unexpected,