Transactions and Web Services

1. Transactions and Web Services Tiziana.Ferrari@cnaf.infn.it INFN – CNAF Corso di Laurea specialistica in Informatica Anno Acc. 2004/2005 Slide sources: 1. Transazioni atomiche, http://www.disi.unige.it/person/GianuzziV/SysOp/lucidi/12_trans.html 2. Implementing Distributed Transactions Transactions

2. Outline • PART I: Atomic Transactions • PART II: Two Phase Commit • PART III: WS-AtomicTransactions and WS-BusinessActivity • PART IV: WS-Coordination • References Transactions

3. PART IAtomic Transactions Transactions

4. Race Condition • La mutua esclusione regola l'accesso concorrente ad una risorsa. Quando un processo ha bisogno di accedere piu' risorse in modo esclusivo, nascono problemi dovuti ad una possibile inconsistenza e/o possibile perdita di dati. • Esempio: Transactions

5. Transazione (Transaction) • Una transazione è una porzione di codice eseguibile delimitato dalle primitive begin-transaction e end-transaction. All'interno si possono usare le primitive read e write (o altre simili) oltre ai soliti statement del linguaggio. Una transazione può anche essere abortita con la primitiva abort-transaction. • Proprietà: • Serializzabilità: le transazioni eseguite concorrentemente non devono interferire in modo scorretto. • Atomicità: la transazione appare all'esterno come una operazione indivisibile. • Permanenza: quando la transazione termina (commit) le modifiche sono permanenti. • L’implementazione dell’atomicità si ottiene attraverso due approcci: • la possibilita' di ritornare nella situazione iniziale della transazione; • esecuzione atomica anche del commit finale, che riassume i criteri dell'istantaneita' e indivisibilita' dell'azione atomica: prima del commit non e' ancora "successo" niente, poi ogni modifica e' visibile e permanente. Transactions

6. Serializzabilità e Permanenza • SERIALIZZABILITA’ • Se due o più transazioni sono eseguite in modo concorrente, il risultato finale deve essere lo stesso di quello ottenuto eseguendo le transazioni in un qualche ordine sequenziale. • Questo criterio è necessario per garantire la consistenza di un un insieme di dati su cui lavorano le transazioni. • L'ordinamento delle primitive read e write di diverse transazioni si chiama schedule ed è consistente, cioè serializzabile, se dopo ogni passo il sistema è ancora consistente. Il problema di determinare se una arbitraria sequenza è serializzabile e' NP-completo. • PERMANENZA • Dopo che una transazione ha effettuato un commit, i risultati devono essere visibili e permanenti. In caso di annidamento di più transazioni, ognuna è committed "relativamente alla transazione parent". Transactions

7. Atomicità • Le transazioni sono chiamate anche talvolta azioni atomiche.L'azione atomica è una astrazione che ha avuto diverse definizioni diverse, ad esempio: • un'azione è atomica se il processo (processi) che la effettua non comunica con altri processi durante l'esecuzione dell'azione (per comunicazione si intende la possibilità di conoscere, in qualsiasi modo, qualche informazione sull'evoluzione di un processo). • se può essere considerata indivisibile ed istantanea, senza stati intermedi visibili. • La condizione di atomicità in particolare, deve essere valida anche in caso errori (crash). Le azioni atomiche devono quindi anche definire un valido strumento per l‘error detection ed il recovery. se durante l'esecuzione di una azione atomica avviene un errore, lo stato di tutti gli oggetti modificati nel corso dell'esecuzione devono essere riportati nelle condizioni precedenti (backward error recovery). Transactions

8. Atomicità: Checkpoint e roll-back (1/2) • Per tornare allo stato iniziale occorre memorizzarlo prima di cominciare la transazione. Sarà poi possibile effettuare un roll-back ad una situazione precedente. Soluzioni: • A. Private work spaceOgni transazione ha il suo private workspace in cui ricopia i dati di stato e i dati che modificherà. Lo stesso avviene per eventuali nested transaction. E' un metodo molto costoso. • B. Utilizzo di shadow dei dati*Solo i dati modificati o aggiunti* sono ricopiati. Gli altri processi vedono quindi sempre i dati originali, finchè un processo non effettua il commit di una transazione. In questo caso il private work space viene ricopiato in modo atomico su quello originale. Questo sistema deve essere accoppiato con un sistema di lock per escludere situazione di inconsistenza dovuto all'accesso concorrente in scrittura da parte di piu' processi in diverse transazioni. • C. Utilizzo di writeahead logI dati di stato vengono effettivamente scritti, ma è mantenuta una traccia delle modifiche sotto forma di coppia vecchio-valore / nuovo-valore. Se la transazione effettua un commit, il log e’ cancellato. Se abortisce, le modifiche apportate sono recuperate (roll-back). Transactions

9. Atomicità: Two Phase Commit Protocol (2/2) • Il two phase commit protocol consente di effettuare il commitment finale se non si verifica un failure. In caso di failure invece e' possibile riparare il guasto (ad esempio rilanciare un processo che si e' interrotto, riconoscere la precedente esecuzione, riportare lo stato del sistema nella posizione corretta....) • Se una transazione abortisce (volontariamente, o per failure di un componente) bisogna riportare il sistema alla situazione precedente, con un'operazioneundo. Occorre quindi memorizzare (su un file log) le operazioni che sono state fatte e le risorse che sono state accedute (per farne poi il roll-back). • Le operazioni possibili sulla transazione sono: • DO: esegue la azione e scrive il log; • UNDO: recupera (torna indietro) le operazioni scritte sul log; • REDO riesegue le operazioni scritte sul log. Transactions

10. Serializzabilità: Algorithmo di Controllo della Concorrenza - Locking • E' il sistema piu' semplice: ogni oggetto ha un solo lock, ottenibile da una sola transazione alla volta. Se una transazione cerca di fare un lock su un oggetto gia' bloccato, puo' : • aspettare, abortire o interrompere (e causarne il roll-back) l'altra transazione, per evitare di finire in deadlock. • Una transazione e' ben formata se: • blocca un oggetto prima di accederlo; • non blocca oggetti gia' bloccati • E' detta two phase se nessun oggetto e' sbloccato prima che tutti quelli che servono siano bloccati. EsempioTransazione T1begin lock  conto A    read  credito A lock  conto B    read  credito B    write credito A-10M su conto A unlock conto A    write  credito B+10M su conto B unlock conto B end Transactions

11. Serializzabilità: Serialization Graphs • Input: schedule S per un insieme di transazioni T1, T2, ..., Tk • Output: viene determinato se S é serializzabile • Metodo: • 1 viene creato un “serialization graph” G tale che: • Nodi: corrispondono alle transazioni • Archi: G ha un arco che collega Ti a Tj se esiste una operazione di Ti UNLOCK (A) che é seguita da una operazione LOCK(A) da parte di Tj all’interno di S • 2 viene studiata la topologia del grafo • Se il grafo G risulta ciclico, allora S noné serializzabile. • Se il grafo G é serializzabile, allora l’ordine delle transazioni corrisponde all’ordine topologico del grafo. Transactions

12. Deadlock e Livelock • Deadlock: stato caratterizzato dall’esaurimento delle risorse disponibili causato dall’intera allocazione della totalità di risorse, tale per cui ogni transazione “blocca” una o più istanze di risorsa, impedendendo alle altre di acquisire le risorse mancanti. Nessuna transazione riesce a raggiungere lo stato di compimento. • Livelock: simile al deadlock, tuttavia, mentre nel deadlock le transazioni attive sono in stato di attesa passiva, in caso di livelock le transazioni continuano ad essere attive, pur non essendo in grado di portare la propria esecuzione a compimento, come nel caso precedente. • Per evitare deadlock e livelock si utilizzano in genere tecniche di deadlock detection con: • interruzione e recovery delle transazioni, e • utilizzo di time-out. Transactions

13. Serializzaione: Time Stamp • Un time stamp e' un numero unico assegnato ad una transazione (ad esempio da un gestore centralizzato, oppure utilizzando un meccanismo distribuito di clock logico) in modo monototono crescente. • Nell'esecuzione delle transazioni si da' la priorita' alle transazioni che hanno il time stamp minore, in modo da garantire l'assenza di starvation. Infatti, una volta assegnato un time stamp ad una transazione (che rimane lo stesso anche se la transazione abortisce e poi ricomincia), solo un numero finito di altre transazioni hanno la priorita' su di essa. Si puo' utilizzare il time stamp nei sistema con lock per evitare il deadlock. Transactions

14. Time Stamp (cont) • Quando una risorsa e' gia' assegnata ad una transazione Tj (con time stamp TSj) e il gestore riceve una richiesta da parte di un'altra transazione Ti con time stamp TSi, puo' effettuare una delle seguenti azioni: • Wait: fare aspettare Ti finche' la risorsa non e' libera. Questa scelta potrebbe portare al deadlock. • Abort-Restart: abortire e riavviare una delle due transazioni: quella che detiene la risorsa o quella che la richiede. Questa scelta potrebbe portare alla starvation. L'operazione abort-restart e' effettuato usando una delle due primitive: • Die: restart della transazione richiedente - Die (Ti). • Wound: la transazione che detiene la risorsa e' segnalata al sistema come "ferita" e si manda un messaggio a tutti i siti visitati dalla transazione ferita: se e' in fase di terminazione (shrinking phase: ha gia' acquisito tutti i lock) la si lascia terminare, altrimenti si effettua un abort-rester (die). • Supponiamo che Tj (time stamp TSj) possieda una risorsa e Ti (TSi) la richieda al suo gestore. Questo puo' applicare uno fra due protocolli di questo tipo molto noti: • Wait-Die • If TSi < TSj  Ti aspetta il rilascio della risorsa ==> Wait (Ti) • If TSi > TSj  Ti viene ucciso, e rilascia le aeventuali altri risorse che possiede. ==> Die (Ti) • Wound-Wait • If TSi < TSj  Tj viene ferita ==> Wound (Tj) • If TSi > TSj  Ti aspetta il suo turno ==> Wait (Ti) Transactions

15. PART IITwo Phase Commit Transactions

16. Global Atomicity • All sub-transactions of a distributed transaction must commit or all must abort • An atomic commit protocol, initiated by a Transaction Manager(e.g., the transaction manager), ensures this. • Transaction Manager must poll Resource Managers to determine if they are all willing to commit • A Resource Manager may need to abort for a number of reasons: • deadlock; • crash of resource manager site; • failure prevents communication with resource manager site; • Conflicts with other transactions (optimistic concurrency control: conflict with other transactions is checked only at commit point). Transactions

17. Atomic Commit Protocol Transaction Manager Resource Manager (3) join transaction (1) tx_begin (4) tx_commit (5) atomic commit protocol Resource Manager (3) join transaction Application program (2) access resources Resource Manager (3) join transaction Transactions

18. Two-Phase Commit Protocol • Most commonly used atomic commit protocol is the two-phase commit protocol. • It mplemented as an exchange of messages between the Transaction Manager and the Resource Managers. • Assumes that the Transaction Manager has created a transaction record for the transaction (when the application called tx_begin) and has appended the Resource Managers’ identities to the record (each time a resource manager register itself). • The transaction record is in volatile memory, as in case of failure of the Transaction Manager, messages from Resource Managers may be lost, with a consequent loss the consistent view hold by the Transaction Manager for each transaction before failure. This is needed to satisfy the Durable property (Atomic, Consistent, Isolated, Durable). Transactions

19. Two-Phase Commit: Overview Application Transaction ManagerResource Manager tx_commit resume - send prepare msg to Res. Manag. in trans. rec. - record vote in trans.rec. - force commit rec. to its log if all vote ready - send commit/abort msg - deallocate trans. rec. - write complete rec. to log in commit case - return status - force prepare rec. to Res. Manager log - send vote msg - local commit/ abort - release locks - send done msg phase 1 (prepare) uncertain period phase 2 (commit) Transactions

20. Two-Phase Commit -- Phase 1 (1/2) • When tx_commit is invoked, the Transaction Manager sendspreparemessage to all Resource Managers • prepare message (Transaction Manager  Resource Manager) : • If Resource Manager wants to abort, it aborts and releases locks • If Resource Manager wants to commit, it moves all update log records to non-volatile store by forcing a prepare record to its log • Guarantees that Resource Manager will be able to commit (despite crashes) if Transaction Manager decides to commit • Resource Manager enters prepared state • Resource Manager sends a vote message (“ready” or “aborting”) • Cannot change its mind, retains all locks if vote is “ready” • Referred to as uncertain period (cannot foretell final outcome) Transactions

21. Two-Phase Commit -- Phase 1 (2/2) • vote message (Resource Manager  Transaction Manager): Resource Manager indicates it is “ready” to commit or is “aborting” • Transaction Manager records vote in transaction record • If any votes are “aborting”, Transaction Manager decides abort • If all are “ready”, Transaction Manager decides commit, forces commit record (containing transaction record) to its log • Transaction committed when commit record is durable • Since all Resource Managers are in prepared state, transaction can be completed despite any failures • Transaction Manager sends commit/abort message to all Resource Managers Transactions

22. Two-Phase Commit -- Phase 2 • commit/abort message (Transaction Manager  Resource Manager): • If commitmessage, Resource Manager commits locally by forcing a commit record to its log • If abortmessage, it aborts • In either case, locks released, uncertain period ends • If commit message, Resource Manager sendsdone message to Transaction Manager • done message (Resource Manager  Transaction Manager): • When Transaction Manager receives done message from all Resource Managers, it writes a complete record to its log and deallocates transaction record from volatile store Transactions

23. Failures and Two-Phase Commit • A participant recognizes two failure situations. • Timeout: No response to a message. Execute a timeout protocol • Crash : On recovery, execute a restart protocol • If a Resource Manager cannot complete the protocol until some failure is repaired, it is said to be blocked • Blocking can impact performance at the Resource Manager site since locks cannot be released Transactions

24. Timeout Protocol • Resource Manager times out waiting for prepare message • Abort the subtransaction • Since the (distributed) transaction cannot commit unless Resource Manager votes to commit, atomicity is preserved • Transaction Manager times out waiting for vote message • Abort the transaction • Since Transaction Manager controls decision, it can force all Resource Managers to abort, preserving atomicity • Resource Manager, in prepared state, times out waiting for commit/abort message • Resource Manager blocked since it does not know Transaction Manager’s decision • Transaction Manager might have decided commit or abort • Resource Manager cannot unilaterally decide and release locks, since its decision might be contrary to Transaction Manager’s decision, violating atomicity • Locks cannot be released • Transaction Manager times out waiting for done message • Request done message from missing Resource Manager Transactions

25. Restart Protocol • Resource Manager finds: • begin_transaction record, but no prepare record: • Abort (transaction cannot have committed because Resource Manager has not voted) • Prepare record, but no commit record (Resource Manager crashed in its uncertain period) • Does not know if transaction committed or aborted • Requests transaction status from Transaction Manager and blocks until it receives an answer • Commit record • Recover transaction to committed state using log • Transaction Manager • On restart: • Search log and restore to volatile memory the transaction record of each transaction for which there is a commit record, but no complete record • On receiving a request from a Resource Manager for transaction status: • If no transaction record in volatile memory, reply abort, else reply based on information in transaction record • Referred to as presumed abort property Transactions

26. Presumed Abort Property • If, when a Resource Manager asks for the status of a transaction, there is no transaction record in Transaction Manager’s volatile storage, either • the Transaction Manager had aborted the transaction and deleted the transaction record • the Transaction Manager had crashed and restarted and did not find the transaction record in its log because: • it was in Phase 1 of the protocol and had not yet made a decision, or • it had previously aborted the transaction Transactions

27. PART III Coordination Protocols:WS-AtomicTransactions and WS-BusinessActivity Transactions

28. Common Agreement Problem: Example • Buyer sends copies of a purchase order to sellers A, B, C • A can’t make a quote, responds with faultmessage • B and C make quotes using completed message • Indicates that B and C have completed successfully • Buyer chooses B • Notifies B using close message • Indicates that B has successfully participated in a terminated business activity • Notifies C using compensate message • Indicates that C should rollback any action it has taken Transactions

29. WS-AtomicTransaction • This specification provides the definition of an atomic transaction coordination type used to coordinate activities having an "all or nothing" property. • Atomic transactions commonly require a high level of trust between participants and are short in duration. • Characteristics of this coordination activity: • actions taken prior to commit are only tentative (i.e., not persistent and not visible to other activities). • When an application finishes, it requests the coordinator to determine the outcome for the transaction. The coordinator determines if there were any processing failures by asking the participants to vote. If the participants all vote that they were able to execute successfully, the coordinator commits all actions taken. If a participant votes that it needs to abort or a participant does not respond at all, the coordinator aborts all actions taken. • Commit makes the tentative actions visible to other transactions. • Abort makes the tentative actions appear as if the actions never happened. Transactions

30. Protocols supported: Completion • Completion: The Completion protocol is used by a single application to tell the coordinator to either try to commit or abort an atomic transaction. After the transaction has completed, a status is returned to the application. • Commit: upon receipt of this notification, the coordinator knows that the participant has completed application processing and that it should attempt to commit the transaction. • Rollback: upon receipt of this notification, the coordinator knows that the participant has terminated application processing and that it should abort the transaction. • Committed: upon receipt of this notification, the initiator knows that the coordinator reached a decision to commit. • Aborted: upon receipt of this notification, the initiator knows that the coordinator reached a decision to abort. Transactions

31. WS-AtomicTransaction Two Phase Commit • The Two-Phase Commit (2PC) protocol is a Coordination protocol that defines how multiple participants reach agreement on the outcome of an atomic transaction. The 2PC protocol has two variants: Durable 2PC and Volatile 2PC. • Volatile: upon receiving a Commit notification in the completion protocol, the root coordinator begins the prepare phase of all participants registered for the Volatile 2PC protocol. • All participants registered for volatile 2PC must respond to coordinator with vote messages before coordinator sends prepare messages to participants registered for durable 2PC • Participant registered for volatile 2PC is not guaranteed to receive commit/abort message from coordinator (since it does not support durable resources, the message serves no purpose) • Durable: After receiving a Commit notification in the completion protocol and upon successfully completing the prepare phase for Volatile 2PC participants, the root coordinator begins the Prepare phase for Durable 2PC participants. All participants registered for this protocol must respond Prepared or ReadOnly before a Commit notification is issued to a participant registered for either protocol. Transactions

32. WS-AtomicTransaction Two Phase Commit (cont) The participant accepts: Prepare: Upon receipt of this notification, the participant knows to enter phase 1 and vote on the outcome of the transaction. If the participant does not know of the transaction, it must vote to abort. If the participant has already voted, it should resend the same vote. Rollback: Upon receipt of this notification, the participant knows to abort, and forget, the transaction. This notification can be sent in either phase 1 or phase 2. Once sent, the coordinator may forget all knowledge of this transaction. Commit: Upon receipt of this notification, the participant knows to commit the transaction. This notification can only be sent after phase 1 and if the participant voted to commit. If the participant does not know of the transaction, it must send a Committed notification to the coordinator. Transactions

33. Business Activities • WS-AtomicTransaction coordination type implements global atomicity • WS-BusinessActivity coordination type is intended for loosely-coupled, long-lived activities that span autonomous web-services • Participants might make state transitions durable and visible immediately • Compensating actions must be used to reverse actions • Participants might withdraw unilaterally while activity is active • Membership in activity is dynamic • Generally constructed from atomic transactions • Activity might span multiple trust domains • Enforcing global atomicity is problematic if systems are unresponsive or untrustworthy Transactions

34. Exceptions and Business Activities • Atomic transactions are designed to handle system generated exceptions (crash, deadlock, communication failure) • Rollback guarantees a return to a consistent state • Inconsistent states are not visible • A business activity generally uses atomic (sub-) transactions to move application from one consistent (intermediate) state to another. • Atomic (sub-) transactions handle system generated exceptions. • Application logic (using compensation) handles application-generated exceptions. • A1 might invoke A2 in a business activity, BA. A2 might create an atomic transaction (different Id), AT. • A2 can commit AT immediately or wait until BA completes Transactions

35. Application-Generated Exceptions (cont) • What do you do if • a service doesn’t respond? • Abort business activity or find another service that does the same thing or continue processing (response is not essential) • a service sends an unanticipated messsage? • Abort business activity or notify initiator or discard message • Since action might depend on application state it is convenient to integrate coordination with the application Transactions

36. WS-BusinessActivity • WS-BusinessActivity coordination type supports two protocols • BusinessAgreementWithParticipantCompletion (BAWPC) • Participant registering for this protocol can initiate termination • BusinessAgreementWithCoordinatorCompletion (BAWCC) • Participant registering for this protocol expects coordinator to tell it when to terminate • Components of same business activity might register for different protocols depending on who is responsible for determining completion • Root application might register for BAWPC, other participants for BAWCC • Cache participant might register for BAWCC; initiator for BAWPC Transactions

37. BAWPC Messages • Completed – analagous to a vote message • Exit – participant leaves the protocol • Cancel – participant is forced out of the protocol by the coordinator • Close/Compensate – in completed state coordinator decides on outcome based on coordination logic specified in context • Fault – participant notifies coordinator that it has failed Transactions

38. PART IV WS-Coordination Transactions

39. Coordination • Refers to the mechanism used by the components of an activity to reach common agreement: • How are components identified? • How are exceptional situations to be handled? • System related failures (e.g., crash, communication failure) • Application related exceptions (e.g., unanticipated messages) • What constitutes successful termination? Transactions

40. Purpose • WS-Coordination is an extensible framework for coordinating activities using: • a coordinator service (activation and registration) • set of coordination protocols (the coordination behavior and the messages exchanged between the coordinator and a participant playing a sepcific role within a coordination type – WSDL specifies the protocol message sequence rules. • This framework enables participants to reach consistent agreement on the outcome of distributed activities. The coordination protocols that can be defined in this framework can accommodate a wide variety of activities, including protocols for simple short-lived operations (atomic transactions) and protocols for complex long-lived business activities. • New coordination protocols can be added (the model is extensible). Transactions

41. Coordination Protocols and Business Activities • WS-AtomicTransaction coordination type implements global atomicity • WS-BusinessActivity coordination type is intended for loosely-coupled, long-lived activities that span autonomous web-services • Participants might make state transitions durable and visible immediately • Compensating actions must be used to reverse actions • Participants might withdraw unilaterally while activity is active • Membership in activity is dynamic • Generally constructed from atomic transactions • Activity might span multiple trust domains • Enforcing global atomicity is problematic if systems are unresponsive or untrustworthy Transactions

42. WS-Coordination • An application that wants to initiate an activity invokes the CreateCoordinationContext() operation of the Activation Service of a coordinator to create a coordination context • Identifier: unique over all activities • CoordinationType: • atomic transaction • business activity • Coordination logic can optionally be specified: e.g., coordinator should use majority rule (or unanimity) in deciding outcome • EndpointReference: used to address the registration service to register for a particular protocol supported by the CoordinationType Transactions

43. Coordination Context • The Creation Context elements are palced within the application message (e.g. the SOAP message header). • Contains: • the activity identifier, • the coordination type (the collection of behaviors supported by the activity) • registration service endpoint reference (that participants can use to register for one or more of the protocols supproted by the activity coordination type) <wsu:Context ...> <wsu:Identifier ...> ... </wsu:Identifier> <wsu:Expires> ... </wsu:Expires>? <!-- extensibility element -- >* </wsu:Context> Transactions

44. Coordination Context: Example <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"     <S:Header> …  <wscoor:CoordinationContext xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"   xmlns:wscoor=“http://schemas.xmlsoap.org/ws/2003/09/wscoor”         xmlns:myApp="http://fabrikam123.com/myApp" S:mustUnderstand="true"> <wsu:Expires> 2002-06-30T13:20:00.000-05:00</wsu:Expires>   <wsu:Identifier> http://Fabrikam123.com/SS/1234</wsu:Identifier> <wscoor:CoordinationType> http://schemas.xmlsoap.org/ws/2003/09/wstx </wscoor:CoordinationType> <wscoor:RegistrationService> <wsa:Address> http://Business456.com/mycoordinationservice/registration </wsa:Address> <wsa:ReferenceProperties>    <myApp:BetaMark> ... </myApp:BetaMark>  <myApp:EBDCode> ... </myApp:EBDCode> </wsa:ReferenceProperties> </wscoor:RegistrationService> <myApp:IsolationLevel>RepeatableRead</myApp:IsolationLevel> </wscoor:CoordinationContext> … </S:Header> Transactions

45. Coordination Service (the Coordinator) 1/2 • Coordination service consists of these component services: • an Activation service with an operation that enables an application to create a coordination instance or context (which contains information about the coordination behavior followed by the application and on how to register into the corresponding activity). • a Registration service with an operation that enables an application to register for coordination protocols; • a coordination type-specific set of coordination protocols. Application Transactions

46. Coordination Service (the Coordinator) 2/2 • Applications use the Activation service to create the coordination context for an activity. Once a coordination context is acquired by an application, it is then sent by whatever appropriate means to another application. • The context contains the necessary information to register into the activity specifying the coordination behavior that the application will follow. • Additionally, an application that receives a coordination context may use the Registration service of the original application or may use one that is specified by an interposing, trusted coordinator. In this manner an arbitrary collection of Web services may coordinate their joint operation Transactions

47. Registration • Once an application has a coordination context from its chosen coordinator, it can register for the activity. The interface provided to an application registering for an activity and for an interposed coordinator registering for an activity is the same. • The requester sends: • Register message contains: • /Register/ProtocolIdentifier : the URI which provides the identifier of the coordination protocol selected for registration. • /Register/ParticipantProtocolService : the Endpoint Reference that the registering participant wants the coordinator to use for the Coordination protocol • The coordinator's registration service responds with: • Registration Response contains: • /RegisterResponse/CoordinatorProtocolService: the Endpoint Reference that the Coordination service wants the registered participant to use for the Coordination protocol. • /RegisterResponse/{any} : Extensibility elements (may be used to convey additional information). Transactions

48. Registration (cont) • The requesting service receives the Registration service Endpoint Reference in the CoordinationContext in an application message. • The Register message targets this Endpoint Reference and includes the participant protocol service Endpoint Reference as a parameter. • The RegisterResponse includes the coordinator's protocol service Endpoint Reference. • At this point, both sides have the Endpoint References of the other's protocol service, so the protocol messages can target the other side. Transactions

49. Creating an Activity 1 • (1) A1 invokesCreateCoordinationContext() to get a context, conA, for a new activity of coordination type Q from coordinator CA. conA : • Activity identifier A1 • Coordination type Q • Endpoint reference to Coordinator A • (2) A1 sends an application message containing the context to A2 • When SOAP is used, the context is a header block with mustUnderstand=“true” • A1 and A2 then use CA’s registration service to register for protocols (perhaps different, but supported by Q). How does this happen?  (1) conA=CCC() CA A1 ) (2) AppMsg(conA) CB A2 Message exchange Transactions

50. Creating an Activity 2 • A2 might want to use a different coordinator • Reasons: performance, trust • Protocol: • (3) A2 invokes CreateCoordinationContext() at coordinator CB, passing conA as a parameter • (4) CB creates a new context, conB, with the same identifier and CoordinationType, returns it to A2 • (5.1) A1 registers for a protocol with CA • (5.2) A2 registers for a protocol with CB and CB registers for the same protocol with CA (1) conA=CCC() CA A1 Register(conA) (5.1) (5.2) (2) Register(conA) AppMsg(conA) (3) conB=CCC(conA) CB A2 Register(conB) (4) Message exchange Transactions