Griglie ComputazionaliTransactions1 Transactions and Web Services INFN – CNAF Corso di Laurea specialistica in Informatica Anno Acc. 2004/2005 Slide sources: 1. Transazioni atomiche, 2. Implementing Distributed Transactions

Griglie ComputazionaliTransactions2 Outline PART I: Atomic Transactions PART II: Two Phase Commit PART III: WS-AtomicTransactions and WS-BusinessActivity PART IV: WS-Coordination References

Griglie ComputazionaliTransactions3 PART I Atomic Transactions

Griglie ComputazionaliTransactions4 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:

Griglie ComputazionaliTransactions5 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à: 1.Serializzabilità: le transazioni eseguite concorrentemente non devono interferire in modo scorretto. 2.Atomicità: la transazione appare all'esterno come una operazione indivisibile. 3.Permanenza: quando la transazione termina (commit) le modifiche sono permanenti. Limplementazione dellatomicità 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.

Griglie ComputazionaliTransactions6 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".

Griglie ComputazionaliTransactions7 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 lerror 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).

Griglie ComputazionaliTransactions8 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 space Ogni 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 log I 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).

Griglie ComputazionaliTransactions9 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'operazione undo. 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.

Griglie ComputazionaliTransactions10 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: 1.blocca un oggetto prima di accederlo; 2.non blocca oggetti gia' bloccati E' detta two phase se nessun oggetto e' sbloccato prima che tutti quelli che servono siano bloccati. Esempio Transazione T1 begin 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

Griglie ComputazionaliTransactions11 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 allinterno 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 lordine delle transazioni corrisponde allordine topologico del grafo.

Griglie ComputazionaliTransactions12 Deadlock e Livelock Deadlock: stato caratterizzato dallesaurimento delle risorse disponibili causato dallintera 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.

Griglie ComputazionaliTransactions13 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.

Griglie ComputazionaliTransactions14 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 Wait (Ti) If TSi > TSj Ti viene ucciso, e rilascia le aeventuali altri risorse che possiede. ==> Die (Ti) – Wound-Wait If TSi Wound (Tj) If TSi > TSj Ti aspetta il suo turno ==> Wait (Ti)

Griglie ComputazionaliTransactions15 PART II Two Phase Commit

Griglie ComputazionaliTransactions16 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).

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

Griglie ComputazionaliTransactions18 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).

Griglie ComputazionaliTransactions19 Two-Phase Commit: Overview Application Transaction Manager Resource 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) phase 2 (commit) uncertain period

Griglie ComputazionaliTransactions20 Two-Phase Commit -- Phase 1 (1/2) When tx_commit is invoked, the Transaction Manager sends prepare message 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)

Griglie ComputazionaliTransactions21 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

Griglie ComputazionaliTransactions22 Two-Phase Commit -- Phase 2 commit/abort message (Transaction Manager Resource Manager): – If commit message, Resource Manager commits locally by forcing a commit record to its log – If abort message, it aborts – In either case, locks released, uncertain period ends – If commit message, Resource Manager sends done 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

Griglie ComputazionaliTransactions23 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

Griglie ComputazionaliTransactions24 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 Managers 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 Managers decision, violating atomicity – Locks cannot be released Transaction Manager times out waiting for done message – Request done message from missing Resource Manager

Griglie ComputazionaliTransactions25 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

Griglie ComputazionaliTransactions26 Presumed Abort Property If, when a Resource Manager asks for the status of a transaction, there is no transaction record in Transaction Managers 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

Griglie ComputazionaliTransactions27 PART III Coordination Protocols: WS-AtomicTransactions and WS-BusinessActivity

Griglie ComputazionaliTransactions28 Common Agreement Problem: Example Buyer sends copies of a purchase order to sellers A, B, C – A cant make a quote, responds with fault message – 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

Griglie ComputazionaliTransactions29 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.

Griglie ComputazionaliTransactions30 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.

Griglie ComputazionaliTransactions31 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.

Griglie ComputazionaliTransactions32 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.

Griglie ComputazionaliTransactions33 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

Griglie ComputazionaliTransactions34 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

Griglie ComputazionaliTransactions35 Application-Generated Exceptions (cont) What do you do if – a service doesnt 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

Griglie ComputazionaliTransactions36 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

Griglie ComputazionaliTransactions37 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

Griglie ComputazionaliTransactions38 PART IV WS-Coordination

Griglie ComputazionaliTransactions39 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?

Griglie ComputazionaliTransactions40 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).

Griglie ComputazionaliTransactions41 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

Griglie ComputazionaliTransactions42 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

Griglie ComputazionaliTransactions43 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) ? *

Griglie ComputazionaliTransactions44 Coordination Context: Example <S:Envelope xmlns:S=" … <wscoor:CoordinationContext xmlns:wsu=" xmlns:wscoor= xmlns:myApp=" S:mustUnderstand="true"> T13:20: : RepeatableRead …

Griglie ComputazionaliTransactions45 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

Griglie ComputazionaliTransactions46 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

Griglie ComputazionaliTransactions47 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).

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

Griglie ComputazionaliTransactions49 Creating an Activity 1 (1) A1 invokes CreateCoordinationContext() to get a context, con A, for a new activity of coordination type Q from coordinator CA. con A : 1.Activity identifier A1 2.Coordination type Q 3.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 CAs registration service to register for protocols (perhaps different, but supported by Q). How does this happen? CA CB A1 A2 con A =CCC() AppMsg(con A ) Message exchange (1) (2) )

Griglie ComputazionaliTransactions50 Creating an Activity 2 A2 might want to use a different coordinator – Reasons: performance, trust Protocol: – (3) A2 invokes CreateCoordinationContext() at coordinator CB, passing con A as a parameter – (4) CB creates a new context, con B, 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 CA CB A1 A2 con A =CCC() Register(con A ) con B =CCC(con A ) Register(con B ) Register(con A ) AppMsg(con A ) Message exchange (1) (2) (5.1) (3) (4) (5.2)

Griglie ComputazionaliTransactions51 Creating an Activity CA CB A1 A2 CBA1 CA A2 con A =CCC() Register(con A ) con B =CCC(con A ) Register(con B ) Register(con A ) AppMsg(con A ) Message exchangeProtocol tree (1) (2) (3) (4) (5)

Griglie ComputazionaliTransactions52 References Distributed Systems; Coulouris, Addison Wesley, Chapter 14. Distributed Operating Systems; A.S.Tanenbaum, Prentice Hall, 1995, Chap Web Services Coordination (WS-Coordination); L.F.Cabrera, G.Copeland, W.Cox, et alt.; Sep Web Services Atomic Transaction (WS-AtomicTransaction); L.F.Cabrera, G.Copeland, B.Fox, et alt.; Sep 2003.