Activity Management and Composition PART IV - contemporary SOA

1. Message Exchange 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 pattern (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 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 [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 The TLS Accounts Payable Service contains a rule that when an invoice header fails validation, an 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 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 complex MEPsPrimitive MEPs can be assembled in various configurations to create different types of messaging models, sometimes called complex MEPs. publish-and- subscribeA classic example is the publish-and- subscribe 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 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 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 ) 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 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 service interaction required to complete business tasks.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 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 Ledger 5. 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. COORDINATION

COORDINATION Every activity introduces a level of context into an application runtime environment. context information –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 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 car washing process also would be classified as context informationFinally, my knowledge of who was doing what in this car washing process also would be classified as context 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 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-specific services These services represent the protocols supported by the coordinator's coordination type. Coordination service Coordination 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 value –Identifier –Identifier (unique) that represents the activity –Coordination type –Coordination type Defines the type of coordination process that the coordination context has been defined for. –Registration service –Registration service Address of the service from which another Web service can request entry into the coordinated process. –Other coordination-specific information –Other 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 completed registration is considered a participant in the coordinated activity.A service that has received a context and has completed registration is considered a participant in the coordinated activity.

The instantiated process The coordination service composition is instantiated when an application service contacts the activation service Via a CreateCoordinationCo ntext 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 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 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 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 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 AtomicAtomic –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 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 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. DurableDurable –richiede che leffetto 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 DB1DB2 Move money transaction Deposit Transaction Withdraw Transaction Per applicazioni distribuite si ha la necessità di mettere insieme transazioni costituite esse stesse da transazioni

Two-Phase Commit (2PC) protocol Assicura latomicità nelle transazioni distribuite Il modello per ciascuna sottotransazione consiste in un piccolo numero di statinumero di stati Ciascuna transazione 2PC richiede un coordinatore che corrisponde alla main transaction coordinatore

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 business transaction modelun business transaction model per definire transazioni a lungo termine, transazioni a breve termine, gestione delle eccezioni e meccanismi di compensazione. set di protocolli di coordinamento (coordination protocols)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. supporto per protocolli di business (business protocolsUn 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 compensazioneAttivazione 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 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 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. 2.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.

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

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 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 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 (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 transactionShort term atomic transaction –Long duration business activityLong 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. business protocola business protocol defines how participants can interoperate to achieve the completion of a business task. process definitionThe 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. 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 singlecontroller web service Collaboration Process flow

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

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 initializedcomputing Ciascuna TR appena partita entra in uno stato in cui esegue la sua local computation precommitted aborted done Internal error failure committed succes forgotten

ESEMPIO di ESECUZIONE di una PC SubTR1 CoordinatorSubTR2 register Quando il coordinatore parte registra le sottotransazioni vote decision Se si ha lunanimità 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

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)

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 Protocol B 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