Griglie ComputazionaliTransactions1 Transactions and Web Services [email protected] INFN...

Griglie Computazionali Transactions 1

Transactions and Web Services

[email protected]

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


Outline

• PART I: Atomic Transactions

• PART II: Two Phase Commit

• PART III: WS-AtomicTransactions and WS-BusinessActivity

• PART IV: WS-Coordination

• References


PART IAtomic Transactions


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:


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.

• 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.


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


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


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


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.


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


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.


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.


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.


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)


PART IITwo Phase Commit


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


Atomic Commit Protocol

Applicationprogram

TransactionManager

ResourceManager

ResourceManager

ResourceManager

(3) join transaction

(3) join transaction

(3) jointransaction

(5) atomiccommitprotocol

(1) tx_begin(4) tx_commit

(2) accessresources


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


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


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)


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


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


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


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


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


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


PART III Coordination Protocols:

WS-AtomicTransactions and WS-BusinessActivity


Common Agreement Problem: Example

• Buyer sends copies of a purchase order to sellers A, B, C– A can’t 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


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.


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.


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.


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.


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


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


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


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


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


PART IV WS-Coordination


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?


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


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


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

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>


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>


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


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 servicesmay coordinate their joint operation


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


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.


Creating an Activity 1• (1) A1 invokes

CreateCoordinationContext() to get a context, conA, for a new activity of coordination type Q from coordinator CA. conA :

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 CA’s registration service to register for protocols (perhaps different, but supported by Q). How does this happen?

CA

CB

A1

A2

conA=CCC()

AppM

sg(conA )

Message exchange

(1)

(2))


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

CA

CB

A1

A2

conA=CCC()

Register(conA)

conB=CCC(conA)

Register(conB)

Reg

iste

r(co

n A) A

ppMsg(con

A )

Message exchange

(1)

(2)

(5.1)

(3)

(4)

(5.2)


Creating an Activity

CA

CB

A1

A2

CB A1

CA

A2

conA=CCC()

Register(conA)

conB=CCC(conA)

Register(conB)

Reg

iste

r(co

n A) A

ppMsg(con

A )

Message exchange Protocol tree

(1)

(2)

(2)

(3)

(4)

(5)


References

• Distributed Systems; Coulouris, Addison Wesley, Chapter 14.

• Distributed Operating Systems; A.S.Tanenbaum, Prentice Hall, 1995, Chap. 3.4.

• Web Services Coordination (WS-Coordination); L.F.Cabrera, G.Copeland, W.Cox, et alt.; Sep 2003.

• Web Services Atomic Transaction (WS-AtomicTransaction); L.F.Cabrera, G.Copeland, B.Fox, et alt.; Sep 2003.

Griglie ComputazionaliTransactions1 Transactions and Web Services [email protected] INFN...

Documents

Transcript of Griglie ComputazionaliTransactions1 Transactions and Web Services [email protected] INFN...