Activity Management and Activity Management and CompositionComposition

Activity Management and Activity Management and CompositionComposition

PART IV - contemporary PART IV - contemporary SOA SOA

PART IV - contemporary PART IV - contemporary SOA SOA

1. Message Exchange 1. Message Exchange Patterns Patterns

1. Message Exchange 1. Message Exchange Patterns Patterns

Message Exchange Consideration

• Every task automated by a Web service can differ – nature of the application logic being executed– the role played by the service

• Regardless of how complex a task is, almost all require the transmission of multiple messages.

• The challenge lies in coordinating these messages in a particular sequence so that the individual actions performed by the message are executed properly and in alignment with the overall business task

MEP

• Message exchange patternMessage exchange pattern (MEP) (MEP) is a template that establishes a pattern for the exchange of messages between SOAP nodes.

– Generalized to Web services, a message exchange pattern is a template that establishes a pattern for the exchange of messages between two communicating parties.

• MEP definitions will therefore be used by several technologies in the Web services architecture:

– communication protocols such as SOAP

– description languages such as WSDL

Primitive MEPs: Request-response

• The request-response MEP establishes a simple exchange in which a message is first transmitted from a source (service requestor) to a destination (service provider). Upon receiving the message, the destination (service provider) then responds with a message back to the source (service requestor).

Case Study 4.1.1

In the Service compositions section, we provided an example where the TLS Accounts Payable Service, upon receiving an invoice submission from a vendor, enlists the TLS Vendor Profile Service to validate the invoice header information.

Case Study 4.1.1 [segue]

The MEP used in this situation is the standard request-response pattern, where a response from the Vendor Profile Service is expected once it receives and processes the original request. The Accounts Payable Service requires a response to ensure that the header details provided in the invoice submission are valid and current

Failure to validate this information terminates the Invoice Submission Process and results in the Accounts Payable Service responding to the vendor with a rejection message.

Primitive MEPs: fire-and-forget• This simple asynchronous pattern is based

on the unidirectional transmission of messages from a source to one or more destinations

Fire-and-forget MEP variations

1. The single-destination pattern, where a source sends a message to one destination only.

2. The multi-cast pattern, where a source sends messages to a predefined set of destinations.

3. The broadcast pattern, which is similar to the multi-cast pattern, except that the message is sent out to a broader range of recipient destinations.

Case Study 4.1.2

The TLS Accounts Payable Service contains a rule that when an invoice header fails validation, an e-mail notification is generated. To execute this step, the Accounts Payable Service sends a message to the Notification Service. This utility service records the message details in a notification log database. (These records are used as the basis for e-mail notifications, as explained in the next example.) Because the message sent from the Accounts Payable Service to the Notification Service requires no response, it uses a single-destination fire-and-forget MEP

Complex MEPs

• Primitive MEPs can be assembled in various configurations to create different types of messaging models, sometimes called complex MEPscomplex MEPs.

• A classic example is the publish-and-publish-and-subscribesubscribe model

The publish-and-subscribe messaging model is a composite of two primitive MEPs

• Step 1 could be implemented by a request-response MEP, where the subscriber's request message, indicating that it wants to subscribe to a topic, is responded to by a message from the publisher, confirming that the subscription succeeded or failed.

• Step 2 then could be supported by one of the fire-and-forget patterns, allowing the publisher to broadcast a series of unidirectional messages to subscribers.

Case Study 4.1.3

The utility Notification Service periodically generates and distributes notification messages for a number of different topics. Messages from outside vendors that fail validation, for example, are first logged in a dedicated notification repository. At the end of every working day, the Notification Service queries this repository to retrieve all failed submissions.It then summarizes specific pieces of information from the query results and uses this data to populate a broadcast notification message. This message is subsequently sent to a list of subscribers consisting primarily of specialized accounting services .These services record the notification data into various profile and account records. Some pass the notification on as an e-mail to select accounting personnel.

MEPs and WSDL• MEPs play a larger role in WSDL service

descriptions as they can coordinate the input

and output messages associated with an

operation. ( esempio )

• WSDL defines several combination of input and

output as part of a PortType description:

– Input-Output Operations.

– Input-Only Operations.

– Output-Input Operations.

– Output-Only Operations.

WSDL support : Request-response operation

• Upon receiving a message, the service must respond with a standard message or a fault message.

WSDL support : Solicit-response operation

• Upon submitting a message to a service requestor, the service expects a standard response message or a fault message.

WSDL support : One-way operation

• The service expects a single message and is not obligated to respond.

WSDL support : Notification operation

• The service sends a message and expects no response.

Punti Chiave 4.1

• An MEP is a generic interaction pattern that defines the message exchange between two services.

• MEPs can be composed to support the creation of

larger, more complex patterns.

• The WSDL specifications support specific variations of common MEPs.

• An MEP is a generic interaction pattern that defines the message exchange between two services.

• MEPs can be composed to support the creation of

larger, more complex patterns.

• The WSDL specifications support specific variations of common MEPs.

2. Service ACTIVITY2. Service ACTIVITY2. Service ACTIVITY2. Service ACTIVITY

Service activity

– In service-oriented solutions, each task can involve any number of services.

• The interaction of a group of services working together to complete a task can be referred to as a service activity

Simple or primitive activity• A simple or primitive activity is typified by

synchronous communication and therefore often consists of two services exchanging information using a standard request-response MEP

Complex activities

• Complex activities, on the other hand, can involve many services (and MEPs) that collaborate to complete multiple processing steps over a long period of time

Service Activity and SOA

• Activities represent any Activities represent any service service

interactioninteraction required to complete required to complete

business tasks. business tasks.

• The scope of a service activity is primarily concerned with the processing and communication between services only

Case Study 4.2.1

1. The initial sender, RailCo's Invoice Submission Service, transmits the invoice message

2. The message is first received by a passive intermediary, which routes the message according to environmental conditions. The message subsequently arrives at TLS's Accounts Payable Service.3. The Accounts Payable Service acts as a controller and initiates a service composition to begin processing the message contents. It begins by interacting with the Vendor Profile Service to validate invoice header data and attaches the invoice document to the vendor account.4. The Accounts Payable Service then extracts taxes, shipping fees, and the invoice total.

It passes these values to the Ledger Service, which updates various ledger accounts, including the General Ledger5. Finally the activity ends, as the Accounts Payable Service completes

its processing cycle by sending a response message back to RailCo

Punti Chiave 4.2

• An activity is a generic concept used to represent a task or a unit of work performed by a set of services.

• The scope of primitive activities can be limited to the completion of simple MEPs.

• Complex activities are common within SOAs and exist as part of any non-trivial service-oriented application

• An activity is a generic concept used to represent a task or a unit of work performed by a set of services.

• The scope of primitive activities can be limited to the completion of simple MEPs.

• Complex activities are common within SOAs and exist as part of any non-trivial service-oriented application

3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION

COORDINATION• Every activity introduces a level of context into an

application runtime environment. – Something that is happening or executing has meaning during

its lifetime, and the description of its meaning (and other characteristics that relate to its existence) can be classified as context informationcontext information.

• The more complex an activity, the more context information it tends to bring with it.

• The complexity of an activity can relate to a number of factors, including:– the amount of services that participate in the activity– the duration of the activity– the frequency with which the nature of the activity changes– whether or not multiple instances of the activity can concurrently

exist

Coordination framework

• provide a means for context information in complex activities to be managed, preserved and/or updated, and distributed to activity participants.

Example

Car wash simple task

chuck

bob

jim

Collect Equipment

Prepare Water

Wash the car

Car wash steps

chuck

bob

jim

I

II

III

bob

II

chuck

jim

III

Locate bucket. - Locate sponge. Locate hose

Car wash considerations

• In this scenario, the bucket availability status is considered context information that I managed.

• Because a separate context manager was in place, Chuck was alleviated of the responsibility of remembering and communicating the context information to Bob.

• This liberate Chuck to continue with his other work.

• It also saved Bob from having to directly locate and communicate with Chuck to get the context information.

• Finally, my knowledge of who was doing what in this Finally, my knowledge of who was doing what in this

car washing process also would be classified as car washing process also would be classified as

context informationcontext information.

Coordinator service model

WS-Coordination establishes a framework that introduces a generic service based on the coordinator service model

This service controls a composition of three other services that each play a specific part in the management of context data.

Coordinator service

Activation serviceActivation serviceResponsible for the creation of a new context and for associating this context to a particular activity

Registration serviceRegistration serviceAllows participating services to use context information received from the activation service to register for a supported context protocol

Protocol-specific Protocol-specific servicesservices

These services represent the protocols supported by the coordinator's coordination type.

Coordination serviceCoordination service. The controller service of this composition

In poche parole …..

Coordination type

• Each coordinator is based on a coordination type, which specifies the nature and underlying logic of an activity for which context information is being managed.

• The WS-Coordination framework can be utilized by different coordination types.– WS-AtomicTransaction– WS-BusinessActivity

• Coordination type extensions provide a set of coordination protocols

Coordination protocol• The actual process that a coordinator uses

to communicate with an application is defined by the coordination protocol chosen by the application.

• The coordination protocol defines a series of messages between the coordinator and each application that is participating in the coordination.

• In a single coordination, each participating Web service application can request to use a different protocol when communicating with the coordinator

Coordination Context• A context created by the activation service is referred to as a

coordination context• The coordination context contains all of the coordination-related

information for a coordinated process and is defined in a SOAP message by the CoordinationContext element in the SOAP message header.

• can contain the following information:– Expiration valueExpiration value

– IdentifierIdentifier (unique) that represents the activity

– Coordination typeCoordination type Defines the type of coordination process that the coordination context has been defined for.

– Registration serviceRegistration service Address of the service from which another Web service can request entry into the coordinated process.

– Other coordination-specific informationOther coordination-specific information The Coordination-Context element is extensible and can be used to carry other application-specific information relating to the coordinated process.

Coordination Partecipants

• service that wants to take part in an activity managed by WS-Coordination must request the coordination context from the activation service.

• It then can use this context information to register for one or more coordination protocols.

• A service that has received a context and has A service that has received a context and has

completed registration is considered a completed registration is considered a

participantparticipant in the coordinated activity. in the coordinated activity.

The instantiated

process

The coordination service composition is instantiated when an application service contacts the activation service

Via a CreateCoordinationContext request message, it asks the activation service to generate a set of new context data. Once passed back with the ReturnContext message, the application service now can invite other services to participate in the coordination.

This invitation consists of the context information the application service originally received from the activation service.

Any Web service in possession of this context information may issue a registration request to the registration service. This allows the service to enlist in a coordination based on a specific protocol.

Upon a successful registration, a service is officially a participant. The registration service passes the service the location of the coordinator service, with which all participants are required to interact.

The completion process

The application service can request that a coordination be completed by issuing a completion request message to the coordination service. The coordinator, in turn,

then issues its own completion request messages to all coordination participants. Each participant service responds with a completion acknowledgement message

Coordination and SOA

Case Study 4.3.1

In the previous case study example, we established the individual process steps that comprised a complex activity. Once the processing of this activity enters the TLS environment, TLS employs a context management system to coordinate the flow of the message through its internal services.

As shown in Figure coordination is applied to the following steps:3. The Accounts Payable Service uses the Vendor Profile Service to validate the invoice header data. If the data is valid, the invoice document is attached to the vendor account.

4. The Accounts Payable Service extracts taxes and shipping fees from the invoice document. These values, along with the invoice total, are submitted to the Ledger Service. The Ledger Service is responsible for updating the General Ledger and numerous sub-ledgers, such as the Accounts Payable Ledger.

A message construct used to request the creation of a context

<CreateCoordinationContext>

<ActivationService>

<wsu:Address> http://www.examples.ws/activation

</wsu:Address>

</ActivationService>

<RequesterReference>

<wsu:Address>

http://www.xmltc.com

</wsu:Address>

</RequesterReference>

<CoordinationType>

http://schemas.xmlsoap.org/ws/2002/08/wstx

</CoordinationType>

</CreateCoordinationContext>

The ActivationService element defines the address of the service that will create (activate) the context.

The RequesterReference element contains the address to which the response message should be sent.

The CoordinationType construct indicates which type of coordinator we would like to create. The use of the http://schemas.xmlsoap.org/ws/2002/08/wstx URI ndicates that we are requesting an atomic transaction coordination type, as specified in the WS-Transaction specification.

Key Points 4.3

• Complex activities tend to introduce the requirement for context data and the subsequent need for this data to be managed and coordinated at runtime.

• WS-Coordination provides a context management framework using a standardized service composition headed by a coordinator service.

• Specialized implementations of this framework are realized through the use of coordination types, such as WS-AtomicTransaction and WS-BusinessActivity.

• By introducing an activity management layer to SOA, coordination promotes service composability and supports the controlled composition of complex activities

• Complex activities tend to introduce the requirement for context data and the subsequent need for this data to be managed and coordinated at runtime.

• WS-Coordination provides a context management framework using a standardized service composition headed by a coordinator service.

• Specialized implementations of this framework are realized through the use of coordination types, such as WS-AtomicTransaction and WS-BusinessActivity.

• By introducing an activity management layer to SOA, coordination promotes service composability and supports the controlled composition of complex activities

4. BUSINESS TRANSACTION 4. BUSINESS TRANSACTION (BT)(BT)

4. BUSINESS TRANSACTION 4. BUSINESS TRANSACTION (BT)(BT)

Transaction

• Termine generico che si riferisce ad ogni attività che crea, aggiorna o cancella i dati in un database

• Quando un set ordinato di operazioni è “modulato” come una transazione allora tutto l’insieme è visto come “one logic operation”– Gli effetti della transazione si vedono quando questa

unica operazione logica si è conclusa con successo– Se l’operazione fallisce allora non è successo niente

ACID• In generale le proprietà delle transazioni

sono conosciute come proprietà ACID, ossia che assicurano Atomicità, Consistenza, Isolamento e Persistenza (Durabilità). – Ad esempio un sistema di gestione di basi di

dati, conduce le transazioni in modo da garantire la consistenza dei “data records” anche quando vengono eseguite più operazioni in concorrenza su di essi.

ACID properties of data• AtomicAtomic

– L’atomicità rappresenta il fatto che la transazione è un’unita indivisibile di esecuzione; o vengono resi visibili tutti gli effetti di una transazione, oppure la transazione non deve avere alcun effetto. Viene quindi seguito un approccio “tutto o niente” dove non è possibile lasciare la transazione in uno degli stati intermedi attraversati durante l’elaborazione

• ConsistentConsistent

– richiede che al termine della transazione tutti i dati manipolati siano coerenti con la semantica della transazione stabilita da una logica di business.

• IsolatedIsolated

– richiede che l’esecuzione di una transazione sia completamente indipendente dalla contemporanea esecuzione di altre transazioni. In un ambiente distribuito l’isolamento nasconde anche gli stati intermedi di una transazioni rendendoli inaccessibili dall’esterno.

• DurableDurable

– richiede che l’effetto di una transazione che abbia eseguito il commit correttamente non venga più perso.

Distributed Transaction

• ACID Properties

• Recovery– Atomicity and

durability

• Concurrency control– Consistency and

Isolation

DB1 DB2

Move money transaction

DepositTransaction

WithdrawTransaction

Per applicazioni distribuite si ha la necessità di mettere insieme transazioni costituite esse stesse da transazioni

Two-Phase Commit (2PC) protocol

• Assicura l’atomicità nelle transazioni distribuite

• Il modello per ciascuna sottotransazione consiste in un piccolo numero di stati

• Ciascuna transazione 2PC richiede un coordinatore che corrisponde alla “main transaction”

Business Transaction

• Con il termine Business Transaction si indica un cambiamento consistente nello stato di un processo condotto tra diverse organizzazioni

• BT Framework ( regole di conduzione delle transazioni che costituiscono il processo ): – strumenti per definire la logica di business– formato e sequenza di messaggi necessari

per conseguire il risultato voluto

Un BTF deve fornire

• un business transaction modelbusiness transaction model per definire transazioni a lungo termine, transazioni a breve termine, gestione delle eccezioni e meccanismi di compensazione.

• un set di protocolli di coordinamento (coordination set di protocolli di coordinamento (coordination protocols)protocols) che permettano di gestire le operazioni eseguite dai vari e-Services e creare il contesto necessario per propagare dati e informazioni tra questi.

• Un supporto per protocolli di business (business supporto per protocolli di business (business protocolsprotocols), e cioè protocolli che definiscano l’ordine con cui i partner si scambiano messaggi e che colgano ogni altro aspetto comportamentale del processo.

BT a breve e a lungo termine• Le BT a breve termine (o BT atomiche) sono costituite da

interazioni su scala ridotta che posso essere eseguite garantendo le proprietà ACID in modo molto simile alle transazioni classiche.

– Una BT atomica vedrà come unico risultato o un commit o un abort;

– in caso di abort è garantito il ritorno allo stato iniziale o tramite roll-back o tramite una compensazione completa.

– Le BT a breve termine possono essere annidate mantenendo tutte le loro caratteristiche.

• Le BT a lungo termine (o semplicemente BT) possono essere viste come un insieme di BT, legate da una logica di business.

– Le singole transazioni possono avere esiti diversi, nel qual caso il risultato finale della BT dipende dalla particolare logica o da una decisione esplicita del cliente che ha iniziato la transazione.

Breve termine vs lungo termine

• Quando si sta eseguendo una transazione tra diversi partner ci saranno alcune operazioni che ognuno di questi può svolgere indipendentemente, e ce ne saranno altre che richiedono il contributo di più parti coinvolte

• Tutto ciò che riguarda una sola organizzazione generalmente viene svolto in una transazione atomica mentre le transazioni a lungo termine si rendono più adatte per gestire le interazioni con gli altri partecipanti, specialmente quando si devono prendere decisioni che non possono essere automatizzate.

Soluzioni per il lungo termine

• Rilascio della rigidità delle proprietà ACID• Attivazione di un meccanismo di compens

azione• Richiesta quindi di protocolli standard

– BUSINESS ACTIVITIESBUSINESS ACTIVITIES

• Quando si eseguono “short duration transactions” e si deve preservare “in the strict sense the ACID properties”– ATOMIC TRANSACTIONSATOMIC TRANSACTIONS

ATOMIC TRANSACTION

• Atomic transactions implement the familiar commit and rollback features to enable cross-service transaction support ( traditional two- phase transaction protocol )

Washing process example• This change to our process affects the following two

steps:4. Fill bucket with warm water.

5. Add soap to water.

• Originally, these steps were simply performed in sequence as a continuation of the overall process.

• Now we have a requirement that dictates that should the resulting soap mixture be unacceptable, the bucket needs to be reset to its original state (empty).

• This requirement emulates an atomic transaction, where at the completion of Step 5, the process is either rolled back to the beginning of Step 4, or the quality of water is accepted (committed) so that it can be applied to washing the car.

WS-AtomicTransaction• used to coordinate activities having an "all or nothing"

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

Two-Phase Commit

• Main protocol used for completing transactions while maintaining the ACID properties of data

• AtomicTransaction specifies two versions of the two-phase commit protocol, known as volatile and durable. – The volatile two-phase commit protocol is used for

coordinating volatile resources, such as an in-memory cache,

– The durable two-phase commit protocol is used for coordinating durable resources, such as a database, from which recovery is possible.

Atomic Transaction Type : five protocols

• Completion

– One participant (generally the application that created the

transaction) registers for the completion protocol, so that it can tell

the coordinator either to try to commit the transaction or force a

rollback. A status is returned to indicate the final transaction

outcome.

• CompletionWithAck

– Same as Completion, but the coordinator must remember the

outcome until receipt of an acknowledgment notification.

• 2PC

Atomic Transaction Type : five protocols

• PhaseZero:

– A participant that wants the coordinator to notify it just before the

2PC protocol begins registers for this. A typical example is an

application that caches data and needs a notification to write

outstanding updates to a database. This is executed prior to the

2PC

• OutcomeNotification:

– A transaction participant that wants to be notified of the commit-abort

decision registers for this. Applications use outcome notifications to

release resources or perform other actions after commit or abort of a

transaction.

The atomic transaction coordinator

• The atomic transaction coordinator plays a key role in managing the participants of the transaction process and in deciding the transaction's ultimate outcome

The atomic transaction process

• the atomic transaction coordinator is tasked with the responsibility of deciding the outcome of a transaction.

• It bases this decision on feedback it receives from all of the transaction participants.

• The collection of this feedback is separated into more phases

the prepare phase • Quando tutte le applicazioni sono state informate delle operazioni

da svolgere, il coordinatore invia un messaggio prepare. • A fronte di questo comando, le applicazioni bloccano le risorse

coinvolte nella transazione ed eseguono le operazioni.

Vote phase• Each participant's vote consists of either a "commit" or "abort"

request• In base al risultato ottenuto comunicano al coordinatore la loro

capacità di eseguire correttamente il commit o meno

Commit Phase• Now reviews all votes and decides whether to commit or rollback

the transaction. • The conditions of a commit decision are simple:

– if all votes are received and if all participants voted to commit, the coordinator declares the transaction successful, and the changes are committed.

– However, if any one vote requests an abort, or if any of the participants fail to respond, then the transaction is aborted, and all changes are rolled back

Examples of a Coordinated Process

• A single coordinator service manages an atomic transaction among three Web services.

• The Web services involved in this transaction are as follows:– An order service that receives orders for products

– An inventory service that provides inventory information from a warehouse

– A shipping service that schedules shipments

– A coordinator service that acts as both the activation service and the registration service for the coordination

• For the MyOrderService application to successfully place an order, it needs to verify both that the inventory for the product is available and that the shipment can be arranged.

• This means that if either MyShippingService or MyInventoryService should fail, the entire transaction cannot succeed.

example

1. After receiving a customer order, MyOrderService sends a CreateCoordinationContext message to MyCoordinator to request a new coordination context for the transaction.

2. MyCoordinator returns a CreateCoordinationContextResponse message containing the coordination context.

3. MyOrderService sends a Register request to the registration service, requesting to use the two-phase commit protocol.

4. The registration service returns a RegisterResponse message.

Steps for example (1)

5. MyOrderService sends an inventory request message to MyInventoryService to check the inventory and mark the requested number of units for shipment. In the header of this message is a CoordinationContext header element with the context identifier and the address of the registration service.

6. MyInventoryService sends a Register message to the registration service to enter into the existing coordination context, also using the two-phase commit protocol.

7. The registration service returns a RegisterResponse message.8. MyInventoryService sends a shipping request message to MyShippingService to

schedule and confirm delivery. In the header of this message is a CoordinationContext header element with the context identifier and the address of the registration service.

Steps for example (2)

9. MyShippingService sends a Register message to the registration service to enter into the existing coordination context, requesting to use the completion with acknowledgment protocol.

10.The registration service returns a RegisterResponse message.11.With all of the services enrolled in the transaction, the coordinator

sends a Prepare message to MyOrderService and MyInventoryService to begin the two-phase commit process. Since MyShippingService isn't using two-phase commit, it doesn't receive the Prepare message

Steps for example (3)

12.After recording the transaction in a recoverable way, MyOrderService and MyInventoryService return a Prepared message to the coordinator.

13.After receiving the Prepared message, the coordinator sends a Commit message to all three services.

14.After successfully committing the changes, MyOrderService and MyInventoryService return a Committed message to the coordinator, and MyShippingService returns a Notified message.

Key Points

• WS-AtomicTransaction is a coordination type that supplies five coordination protocols that can be used to achieve two-phase commit transactions across multiple service participants.

• The atomic transaction coordinator makes the ultimate decision to commit or rollback a transaction. This decision is based on votes collected from participants.

Final Considerations1. Il punto fondamentale di questo protocollo è quindi il

blocco delle risorse finché non si è sicuri che tutto sia stato eseguito correttamente. Questa pratica non è adatta in ambiente Web.

1. In primo luogo il Web è caratterizzato da comunicazioni asincrone e non affidabili ; questo ostacola l’implementazione di un protocollo 2PC in quanto il coordinatore non può essere certo del tempo impiegato da un partecipante a rispondere ai suoi messaggi di prepare e di commit e rischia di attendere indefinitamente.

2. Anche l’uso di timeout per ovviare a questo problema non offre una valida soluzione perché timeout troppo corti possono causare l’abort di un numero eccessivo di transazioni che invece sarebbero andate a buon fine, mentre timeout troppo lunghi possono tenere molte risorse bloccate inutilmente per tempi inaccettabili.

Final Considerations2. Secondariamente bisogna considerare che

un’organizzazione che partecipi ad una transazione difficilmente sarebbe disposta a bloccare le proprie risorse per lungo tempo.

1. È principalmente per questi motivi che si è ormai diffusa l’idea di rilassare i vincoli imposti dalle proprietà ACID quando si ha a che fare con BT a lungo termine che spaziano tra i domini di più organizzazioni diverse.

2. Data la loro natura, le BT a breve termine possono essere implementate secondo i classici protocolli 2PC. Tipicamente infatti le operazioni di una BT a breve termine sono completamente automatizzate (e quindi eseguite in tempi brevissimi) e non escono dai confini di un’organizzazione.

BT a lungo termine• Viene considerata come un insieme di

transazioni a breve termine. • Il coordinatore fa in modo che ognuna di queste

venga eseguita indipendentemente dalle altre e raccoglie i vari esiti che gli giungeranno in diversi istanti di tempo. Generalmente alcuni saranno dei commit e altri degli abort.

• A seconda di quali transazioni sono andate a buon fine e quali no, verrà presa una decisione (da una specifica applicazione di business o direttamente dal cliente) sull’esito globale della BT.

Not offer rollback capabilities

COMPENSATION PROCESSCOMPENSATION PROCESS

Business activity protocols

• The BusinessAgreementWithParticipantCompletion protocol, which allows a participant to determine when it has completed its part in the business activity.

• The BusinessAgreementWithCoordinatorCompletion protocol, which requires that a participant rely on coordinator to notify it that it has no further processing responsibilities.

Business activity coordinator

Abort di una BT e compensazione• Quando una transazione atomica fallisce viene garantito un roll-

back automatico, ma per una BT occorre attivare transazioni di compensazione che svolgano le operazioni inverse di quelle fatte da tutte le transazioni che inizialmente avevano eseguito il commit.

• Questo approccio, noto come backward recovery, non è sempre possibile poiché può capitare che alcune operazioni siano irreversibili.

– In questo caso si deve procede secondo un altro approccio (forward recovery) che dà il via a nuove transazioni le quali, preso atto dei cambiamenti ormai avvenuti, riconducono il processo ad uno stato “simile” a quello di partenza.

– Una situazione di questo tipo può verificarsi, ad esempio, quando viene annullato un ordine per l’acquisto di merci che sono già state spedite. Infatti, anche se le merci vengono rimandate indietro, bisogna comunque far fronte alle spese di spedizione e di conseguenza lo stato finale non potrà mai essere uguale a quello di partenza..

Business activity states (1/2)

• Active State• Completed state

– a participant can indicate that it has completed the processing it was required to perform as part of the activity by issuing a completed notification.

– This moves the participant from an active state to a completed state.

– The coordinator may respond with a close message to let the participant know that the business activity is being successfully completed.

• Compensation state– Participants can enter a compensation state during which they

attempt to perform some measure of exception handling. This generally invokes a separate compensation process that could involve a series of additional processing steps.

Business activity states (2/2)

• Cancelled state– Alternatively to compensation state;– This typically results in the termination of any further processing

outside of the cancellation notifications that need to be distributed

• Exit state– What also distinguishes business activities from atomic

transactions is the fact that participating services are not required to remain participants for the duration of the activity.

– Because there is no tight control over the changes performed by services, they may leave the business activity after their individual contributions have been performed.

– When doing so, participants enter an exit state by issuing an exit notification message to the business activity coordinator.

Business activity and atomic transactions

Key Points

• Business activities manage complex, long-running activities

that can vary in scope and in the amount of participating

services.

• WS-BusinessActivity builds on the WS-Coordination context

management framework by providing two protocols for

which activity participants can register.

• Participants and the business activity coordinator progress

through a series of states during the lifespan of a business

activity. State transition is accomplished through the

exchange of notification messages.

Web Service Transaction Summary

• WS-Atomic Transaction and WS-

BusinessActivity “leverage” WS-Coordination

definendo due tipi di coordinamento :

– Short term atomic transaction

– Long duration business activity

ORCHESTRATION

• With orchestration, different processes can be connected without having to redevelop the solutions that originally automated the processes individually.

• Orchestration bridges this gap by introducing new workflow logic.

• Further, the use of orchestration can significantly reduce the complexity of solution environments.

• Workflow logic is abstracted and more easily maintained than when embedded within individual solution components.

Orchestration Control

Language specification

• A primary industry specification that standardizes orchestration is the Web Services Business Process Execution Language (WS-BPEL).

• WS-BPEL is the most recent name given to this specification, which also is known as BPEL4WS and just BPEL.

Business protocols and process definition

• The workflow logic that comprises an orchestration can consist of numerous business rules, conditions, and events.

• a business protocolbusiness protocol defines how participants can interoperate to achieve the completion of a business task.

• The details of the workflow logic encapsulated and expressed by an orchestration are contained within a process definitionprocess definition.

Process services and partner services

• First, the process itself is represented as a service, resulting in a process service

• Other services allowed to interact with the process service are identified as partner services or partner links

Basic activities and structured activities

• WS-BPEL breaks down workflow logic into a series of predefined primitive activities.

• Basic activities (receive, invoke, reply, throw, wait) represent fundamental workflow actions which can be assembled using the logic supplied by structured activities (sequence, switch, while, flow, pick).

Some activities

• Sequence – aligns groups of related activities into a list that

determines a sequential execution order.

• Flows – also contain groups of related activities, but they

introduce different execution requirements.

• Links – are used to establish formal dependencies between

activities that are part of flows. Before an activity fully can complete, it must ensure that any requirements established in outgoing links first are met.

Orchestration and coordination

Orchestration, as represented by WS-BPEL, can

fully utilize the WS-Coordination context

management framework by incorporating the

WS-BusinessActivity coordination type.

Orchestration, as represented by WS-BPEL, can

fully utilize the WS-Coordination context

management framework by incorporating the

WS-BusinessActivity coordination type.

Key Points• An orchestration expresses a body of business process

logic that is typically owned by a single organization.

• An orchestration establishes a business protocol that

formally defines a business process definition.

• The workflow logic within an orchestration is broken

down into a series of basic and structured activities that

can be organized into sequences and flows.

• Orchestration has been called the "heart of SOA," as it

establishes a means of centralizing and controlling a

great deal of inter and intra-application logic through a

standardized service model.

• An orchestration expresses a body of business process

logic that is typically owned by a single organization.

• An orchestration establishes a business protocol that

formally defines a business process definition.

• The workflow logic within an orchestration is broken

down into a series of basic and structured activities that

can be organized into sequences and flows.

• Orchestration has been called the "heart of SOA," as it

establishes a means of centralizing and controlling a

great deal of inter and intra-application logic through a

standardized service model.

Choreography

• A choreography is essentially a collaboration process designed to allow organizations to interact in an environment that is not owned by any one partner.

• The Web Services Choreography Description Language (WS-CDL) is one of several specifications that attempts to organize information exchange between multiple organizations (or even multiple applications within organizations), with an emphasis on public collaboration

A choreography enables collaboration between its participants.

Choreography elements

• Roles

– This establishes what the service does

• Relationship

– Each potential exchange between two roles

• Channels

– defining the characteristics of the message exchange between two specific roles

Interactions and work units

• Interactions are the fundamental building blocks of choreographies. – the completion of an interaction represents

actual progress within a choreography.

• Related to interactions are work units. – These impose rules and constraints that must

be adhered to for an interaction to successfully complete

Orchestrations and choreographies

• While both represent complex message interchange patterns, there is a common distinction that separates the terms "orchestration" and "choreography."

• An orchestration expresses organization-specific business workflow. – This means that an organization owns and controls the logic

behind an orchestration, even if that logic involves interaction with external business partners.

• The choreography acts as a community interchange pattern used for collaborative purposes by services from different provider entities – A choreography, on the other hand, is not necessarily owned by

a single entity.

A choreography enabling collaboration between two different orchestrations

Orchestrations and choreographies

• One can view an orchestration as a business-specific application of a choreography. – This view is somewhat accurate, only it is muddled by the fact

that some of the functionality provided by the corresponding specifications (WS-CDL and WS-BPEL) actually overlaps.

– This is a consequence of these specifications being developed in isolation and submitted to separate standards organizations (W3C and OASIS, respectively).

• An orchestration is based on a model where the composition logic is executed and controlled in a centralized manner.

• A choreography typically assumes that there is no single owner of collaboration logic.

Web Services Orchestration

• Execution order of web services interactions

• Describes process flow• Includes internal and external

webservices• Process is always controlled by

one party

webservice

webservice

webservice

Web Services Choreography

• Tracks the sequence of messages involving multiple parties and sources

• Public message exchanges, not executable processes

• Collaborative - no single “controller”

webservice

webservice

webservice

Collaboration

Process flow

Example of Web Services Composition

Orchestration-Centric Approach

receive 'OpenAccountRequest'

invoke CollectAccountInfoinvoke ValidateAccountInfoassign AccountInfoInvalid = ValidateAccountInfoResponsewhile AccountInfoInvalid = true invoke RepairAccountInfo pick onRepairAccountInfoCB invoke ValidateAccountInfo assign AccountInfoInvalid = ValidateAccountInfoResponse otherwise // timeout - assume AccountInfo can't be repaired invoke DeclineAccountApplication terminate end pickend whileinvoke OpenAccountinvoke SendConfirmation

Choreography-Centric Approach

•CollectAccountInformation and

ValidateAccountInformation

•ValidateAccountInformation and

RepairAccountInformation.

•ValidateAccountInformation and

OpenAccount.

•OpenAccount and

SendConfirmation.

•RepairAccountInformation and

DeclineAccountApplication

KEY POINTS

• A choreography is a complex activity comprised of a service composition and a series of MEPs.

• Choreographies consist of multiple participants that can assume different roles and that have different relationships.

• Choreographies are reusable, composable, and can be modularized.

LIFE CYCLE di una transazione che può partecipare come sottotransazione in 2PC

initialized computing

Ciascuna TR appena partita entra in uno stato in cui esegue la sua local computation

precommitted

aborted

done

Internal

error failurecommitted

succes

forgotten

ESEMPIO di ESECUZIONE di una “PC

SubTR1SubTR1 CoordinatorCoordinator SubTR2SubTR2

register register

Quando il coordinatore parte registra le sottotransazioni

vote vote

decision decision

Se si ha l’unanimità di commit allora il coordinatore annuncia una commit decisione altrimenti un abort decision ( rollback)

• Ogni partecipante può aggiornare il suo

stato dopo ciascun passo della

transazione

• I risultati di un task sono visibili prima della

fine della transazione

• I vincoli di atomicità ed Isolamento sono

“relaxed”

• L’operazione di compensazione in caso di fallimento fa perdere semanticamente gli effetti dell’esecuzione parziale della transazione

• Ciascuna operazione può avere una differente logica di compensazione

• Ciascun provider può avere una differente opinione riguardo l’esatto significato di compensare una operazione– Disdetta reservation con pagamento penale o

no

Short term atomic transaction (example)

• Travel agency deve trovare un volo per un cliente che deve visitare un museo

• Travel Agency e Airline hanno i propri coordinatori (registration ed activation service)

Travel Agency Server

WS

COORD.

Airline Server

WS

COORD.

Museum Server

WS

(1) commit

1. Ws Travel tenta di iniziare una transazione usando Completion Protocol

2. Il coordinatore inizia ad eseguire il protocollo di coordinamento per gli altri due partecipanti inviando un messaggio di PREPARE del 2PC protocol

3. I servizi coinvolti si dichiarano pronti ad eccezione del museo che risponde con un messaggio ed abbandona la transazione

(2)prepare

(3)prepare(4) prepare

(6)prepared

(5) prepared

(7) message

Travel Agency Server

WS

COORD.

Airline Server

WS

COORD.

Notifica del voto e votazione

(8) vote

(9) vote (10) voted

(11) voted

(12) voted

Business Activity example

• Tre web services (A B C) con un coordinatore R

• A inizia il protocollo mentre B e C vi partecipano

A inizia la Business Activity e passa il contesto a B e C che si registrano con R per il BusinessAgreement ProtocolB finisce il suo lavoro mentre C incontra un errore Se quando riceve il fault message R ha già ricevuto il messaggio completed da B manda a B un messaggiio “compensate” altrimenti “cancelled”

Infine R manda un forget message to C

Web service A Web service B Web service C Coordinator R

create CC

A1

operational message

register for BusinessAgreement

BusinessAgreement coordinator

operational message

register for BusinessAgreement

BusinessAgreement coordinator

completed

faulted

compensate

forget

HelloService.wsdl