CONTEMPORARY SOA

ACTIVITY MANAGEMENT AND COMPOSITION

1. MESSAGE EXCHANGE PATTERNS

Message Exchange Consideration

Every task automated by a Web service can differ in both the nature of the application logic being executed and the role played by the service in the overall execution of the business task. 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 pattern (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 MEPs. A classic example is the publish publish-and andsubscribe 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.

 WS-* specification the incorporate this messaging model include:

WS-BaseNotification WS-BrokeredNotification WS-Topics WS-Eventing

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

WSDL 2.0
In-out pattern Out-in pattern In-only pattern Out-only pattern Robust in-only pattern Robust out-only pattern In-optional-out pattern Out-optional-in pattern

MEPs and SOAP

SOAP standard provides a messaging framework designed to support message transfer. One way Message Pattern SOAP 1.2 defines the MEP standard:
Request-Response SOAP Response

Summary
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 and SOAP specifications support specific variations of common MEPs.

2. 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 requestresponse 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 service

interaction required to complete

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 conditions. The message ata TLS's Accounts Payable Service. 3. environmental The Accounts Payable Service acts as a subsequently controller andarrives initiates service composition to begin processing the message contents. It begins by interacting with the Vendor Profile Service to validate header data and attaches the invoice document the and vendor 4. The invoice Accounts Payable Service then extracts taxes, shipping to fees, the account. invoice total. It passes these values to the Ledger Service, which updates various ledger accounts, including the General Ledger 5. Finally the activity ends, as the Accounts Payable Service completes its processing cycle by sending a response message back to RailCo

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

Collect Equipment chuck

bob

Prepare Water

Wash the car jim

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.

Services of Coordinator Composition

Activation service
Responsible for the creation of a new context and for associating this context to a particular activity.

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

Protocol Protocol-specific services

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

Coordination service.
The controller service of this composition

Coordinator service

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 is extensible and 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 value Identifier (unique) that represents the activity Coordination type Defines the type of coordination process that the coordination context has been defined for. Registration service Address of the service from which another Web service can request entry into the coordinated process. Other coordinationcoordination-specific information The Coordination-Context element is extensible and can be used to carry other application-specific information relating to the coordinated process.

Coordination Participants
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 completed registration is considered a participant in the coordinated activity.

This invitation consists of the context information Upon a the application successful service originally registration, a received from the service is officially Any Web service activation service. a participant. The in possession of registration this context service information Via a passesmay the service The coordination issue a the CreateCoordinationCo location of the service composition is registration ntext request coordinator instantiated an request to the the message, it when asks service, with application serviceto registration activation service which all the contacts activation service. This generate a set of new participants are service allowsdata. the service context Once required to to enlist in a passed back with the interact. coordination ReturnContext based on a message, the specific protocol. application service now can invite other services to participate in the coordination.

The instantiated process

The completion process

The application service can request that a coordination be completed by issuing a completion request message to the The coordinator, in turn, coordination service. 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

As shown in Figure coordination is applied to the following steps: 3. The Accounts Payable Service uses the Vendor Profile Service to validate the In the previous case study example, the individual invoice header data. If the data is valid, we the established invoice document is attached to the process steps that comprised a complex activity. Once the processing vendor account. of this activity enters the TLS environment, TLS employs a context management to coordinate the flow ofand the shipping messagefees through 4. The Accounts system Payable Service extracts taxes fromits the internal services. 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/2 002/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

4. BUSINESS TRANSACTION (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 linsieme visto come one logic operation
Gli effetti della transazione si vedono quando questa unica operazione logica si conclusa con successo Se loperazione 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

Atomic
Latomicit rappresenta il fatto che la transazione ununita 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 lelaborazione

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

Isolated
richiede che lesecuzione di una transazione sia completamente indipendente dalla contemporanea esecuzione di altre transazioni. In un ambiente distribuito lisolamento nasconde anche gli stati intermedi di una transazioni rendendoli inaccessibili dallesterno.

Durable
richiede che leffetto di una transazione che abbia eseguito il commit correttamente non venga pi perso.

Distributed Transaction
Move money transaction

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

Deposit Transaction

Withdraw Transaction

ACID Properties Recovery

Atomicity and durability

DB1

DB2

Concurrency control
Consistency and isolation

Two-Phase Commit (2PC) protocol

Assicura latomicit 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 Lautomazione di processi di business complessi non pu essere realizzata adeguatamente con gli attuali sistemi di scambi di messaggi

BT Framework
Apposito framework che assicuri che le transazioni che costituiscono il processo siano condotte secondo specifiche regole:
strumenti per definire la logica di business formato e sequenza di messaggi necessari per conseguire il risultato voluto

La sincronizzazione delle attivit che vengono svolte allinterno dei singoli partecipanti al processo deve essere gestita tenendo conto della natura dello scenario dove avviene la comunicazione (ad esempio il Web);

Un BTF deve fornire

un business 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 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 protocols), e cio protocolli che definiscano lordine 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 compensazione Richiesta quindi di protocolli standard
BUSINESS ACTIVITIES

Quando si eseguono short duration transactions e si deve preservare in the strict sense the ACID properties
ATOMIC TRANSACTIONS

ATOMIC TRANSACTION
Atomic transactions implement the familiar commit and rollback features to enable crossservice transaction support ( traditional twophase 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.

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

This particular implementation of the WS-Coordination coordinator service represents a specific service model. 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 twophase 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 Considerations
1. 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 limplementazione 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. Anche luso di timeout per ovviare a questo problema non offre una valida soluzione perch timeout troppo corti possono causare labort 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.

2.

Final Considerations
2. Secondariamente bisogna considerare che unorganizzazione 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 lidea 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. 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 unorganizzazione.

2.

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) sullesito globale della BT.

Not offer rollback capabilities

COMPENSATION 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 rollback automatico, ma per una BT occorre iniziare delle 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 lacquisto 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

During the lifecycle of a business activity, the coordinator and the participants transition through a series of states. The actual point of transition occurs when special notification messages are passed between these services States are defined in a series of state tables documented as part of the WS-BusinessActivity specification. These tables establish the fundamental rules of the business activity protocols by determining the sequence and conditions of allowable states.

State example
Active State Completed state
For example, 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.

State example
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 WSBusinessActivity 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. Collectively, these parts of an orchestration establish a business protocol that 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 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.

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.

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
web service

Web Services Choreography

Tracks the sequence of messages involving multiple parties and sources Public message exchanges, not executable processes Collaborative - no single controller
web service

Collaboration
web service

Process flow

web service web service

web service

Example of Web Services Composition

Orchestration-Centric Approach
receive 'OpenAccountRequest' invoke CollectAccountInfo invoke ValidateAccountInfo assign AccountInfoInvalid = ValidateAccountInfoResponse while AccountInfoInvalid = true invoke RepairAccountInfo pick onRepairAccountInfoCB invoke ValidateAccountInfo assign AccountInfoInvalid = ValidateAccountInfoResponse otherwise // timeout assume AccountInfo can't be repaired invoke DeclineAccountApplication terminate end pick end while invoke OpenAccount invoke SendConfirmation

Choreography-Centric Approach
CollectAccountInformation and ValidateAccountInformation ValidateAccountInformation and RepairAccountInformation. ValidateAccountInformation and OpenAccount. OpenAccount and SendConfirmation. RepairAccountInformation and DeclineAccountApplication

Comparing Orchestration-Centric and Choreography-Centric Approaches

In general, the choreography-centric approach is more loosely coupled.
It is particularly well suited when portions of the process span administrative and organizational boundaries, which makes it difficult (if not impossible) to synchronize internal processes; however, it is much more important to define and specify the business protocol linking the partners (even if the "partners" are simply departments in the same company).

One key difference is that the orchestration approach assumes a single, central point of control over the entire scope of the process execution, while the choreography approach assumes that execution control is shared, potentially across multiple business process engines or various other technologies.

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.

Request-Response MEP

SOAP Response MEP

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

done initialized computing precommitted

Internal error failure

committed

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

aborted

forgotten

ESEMPIO di ESECUZIONE di una PC

SubTR1

Coordinator

SubTR2 Quando il coordinatore parte registra le sottotransazioni Se si ha lunanimit di commit allora il coordinatore annuncia una commit decisione altrimenti un abort decision ( rollback)

register

register

vote

vote

decision

decision

 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

 Loperazione di compensazione in caso di fallimento fa perdere semanticamente gli effetti dellesecuzione parziale della transazione Ciascuna operazione pu avere una differente logica di compensazione Ciascun provider pu avere una differente opinione riguardo lesatto 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)

Museum Server

Travel Agency Server WS

(1) commit

Airline Server WS
(4) prepare (5) (3)prepare prepared (6)prepared

WS

(2)prepare

COORD.
(7) message

COORD.

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

Travel Agency Server

Airline Server

WS
(9) vote (12) voted (8) vote

WS
(10) voted

COORD.

COORD.

(11) voted

Notifica del voto e votazione

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 B finisce il suo lavoro mentre C incontra quando riceve il fault message R ha un gierrore ricevuto il messaggio completed RSe per il BusinessAgreement Protocol da B manda a B un messaggiio compensate altrimenti cancelled Infine R manda un forget message to C