contemporary soa - i

7/27/2019 Contemporary SOA - I

1/122

CONTEMPORARYCONTEMPORARYCONTEMPORARYCONTEMPORARYCONTEMPORARYCONTEMPORARYCONTEMPORARYCONTEMPORARY SOASOASOASOASOASOASOASOA

ACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT ANDACTIVITY MANAGEMENT AND

COMPOSITIONCOMPOSITIONCOMPOSITIONCOMPOSITIONCOMPOSITIONCOMPOSITIONCOMPOSITIONCOMPOSITION


2/122

1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGEPATTERNSPATTERNSPATTERNSPATTERNSPATTERNSPATTERNSPATTERNSPATTERNS


3/122

Message Exchange Consideration Every task automated by a Web service can

differ in both the nature of the application logicbeing executed and the role played by theservice in the overall execution of the businesstask.

Regardless of how complex a task is, almost allrequire the transmission of multiple messages. The challenge lies in coordinating these

messages in a particular sequence so that theindividual actions performed by the message areexecuted properly and in alignment with theoverall business task


4/122

MEP Message exchange patternMessage exchange pattern(MEP)(MEP) is a template thatestablishes 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

communicating parties.

MEP definitions will therefore be used by severaltechnologies in the Web services architecture:

communication protocols such as SOAP

description languages such as WSDL


5/122

Primitive MEPs: Request-response

The request-responseMEP establishes a simpleexchange in which a message is first transmittedfrom a source (service requestor) to adestination (service provider). Upon receivingthe message, the destination (service provider)then responds with a message back to the

source (service requestor).


6/122

Case Study 4.1.1

In the Service compositionssection, we provided anexample where the TLS

ccounts aya e erv ce,upon receiving an invoicesubmission from a vendor,enlists the TLS VendorProfile Service to validate the

invoice header information.


7/122

Case Study 4.1.1 [segue]The MEP used in this situation is the standard request-responsepattern, where a response from the Vendor Profile Service is

expected once it receives and processes the original request. TheAccounts Payable Service requires a response to ensure that theheader details provided in the invoice submission are valid andcurrent

Failure to validate this information terminates the InvoiceSubmission Process and results in the Accounts Payable Serviceresponding to the vendor with a rejection message.


8/122

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

on the unidirectional transmission ofmessages from a source to one or moredestinations


9/122

Fire-and-forget MEP variations1. The single-destinationpattern, where a source

sends a message to one destination only.2. The multi-castpattern, where a source sends

messages to a predefined set of destinations.

3. The broadcastpattern, which is similar to themulti-cast pattern, except that the message issent out to a broader range of recipient

destinations.


10/122

Case Study 4.1.2The TLS Accounts Payable Service contains a rule that when an invoiceheader fails validation, an e-mail notification is generated. To execute thisstep, the Accounts Payable Service sends a message to the Notification

Service. This utility service records the message details in a notificationlog database. (These records are used as the basis for e-mailnotifications, as explained in the next example.) Because the messagesent from the Accounts Payable Service to the Notification Service

, - - -


11/122

Complex MEPs Primitive MEPs can be assembled in

various configurations to create differenttypes of messaging models, sometimes

. A classic example is the publishpublish--andand--

subscribesubscribemodel


12/122

The publish-and-subscribe messaging

model is a composite of two primitive MEPs Step 1 could be implemented by a

request-response MEP, where thesubscriber's request message,indicating that it wants tosubscribe to a topic, is responded

publisher, confirming that thesubscription succeeded or failed.

Step 2 then could be supported byone of the fire-and-forget patterns,

allowing the publisher tobroadcast a series ofunidirectional messages tosubscribers.


13/122

Case Study 4.1.3The utility Notification Service periodically generates and distributesnotification messages for a number of different topics. Messages fromoutside vendors that fail validation, for example, are first logged in adedicated notification repository. At the end of every working day, the

Notification Service queries this repository to retrieve all failedsubmissions.It then summarizes specific pieces of information from the queryresults and uses this data to populate a broadcast notificationmessage. This message is subsequently sent to a list of subscribersconsisting primarily of specialized accounting services .These services record the notification data into various profile andaccount records. Some pass the notification on as an e-mail to selectaccounting personnel.


14/122

WS-* specification the incorporate this

messaging model include: WS-BaseNotification - WS-Topics WS-Eventing


15/122

MEPs and WSDL MEPs play a larger role in WSDL service

descriptions as they can coordinate the input

and output messages associated with anoperation.

e nes severa com na on o npu anoutput as part of a PortType description:

Input-Output Operations.

Input-Only Operations.

Output-Input Operations.

Output-Only Operations.


16/122

WSDL support : Request-responseoperation

Upon receiving a message, the service

must respond with a standard message ora fault message.


17/122

WSDL support : Solicit-responseoperation

Upon submitting a message to a service

requestor, the service expects a standardresponse message or a fault message.


18/122

WSDL support : One-way operation The service expects a single message and

is not obligated to respond.


19/122

WSDL support : Notificationoperation

The service sends a message and expects

no response.


20/122

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


21/122

MEPs and SOAP SOAP standard provides a messaging

framework designed to support messagetransfer. One way Message Pattern

. e nes t e stan ar : Request-Response SOAP Response


22/122

Summary

An MEP is a generic interaction pattern that defines themessage exchange between two services.

MEPs can be com osed to su ort the creation of

larger, more complex patterns.

The WSDL and SOAP specifications support specific

variations of common MEPs.


23/122

2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY


24/122

Service activity In service-oriented solutions, each task can

involve any number of services. The interaction of a group of services

be referred to as a service activity


25/122

Simple or primitive activity A simple or primitive activityis typified bysynchronous communication and thereforeoften consists of two services exchanginginformation using a standard request-


26/122

Complex activities Complex activities, on the other hand, can

involve many services (and MEPs) thatcollaborate to complete multiple processingsteps over a long period of time


27/122

Service Activity and SOA Activities represent anyActivities represent any serviceservice

interactioninteraction required to completerequired to complete

us ness tas s.us ness tas s. The scope of a service activity is primarily

concerned with the processing andcommunication between services only


28/122

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 accordingto environmental conditions. The message subsequently arrives at TLS's Accounts Payable Servic3. The Accounts Payable Service acts as a controller and initiates a service composition to beginprocessing the message contents. It begins by interacting with the Vendor Profile Service tovalidate 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 completesits processing cycle by sending a response message back to RailCo


29/122


30/122

3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION


31/122

COORDINATION Every activity introduces a level of context into an application

runtime environment.

Something that is happening or executing has meaning during itslifetime, and the description of its meaning (and other characteristicsthat relate to its existence) can be classified as contextcontextinformationinformation.

The more com lex an activit the more context information ittends 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


32/122

Coordination framework

provide a meansfor contextinformation incomplex activitiesto be managed,

preserved and/orupdated, anddistributed toactivity

participants.


33/122

Example


34/122

Car wash simple task

chuck

Collect Equipment

bob

jim

Prepare Water

Wash the car


35/122

Coordinator service modelWS-Coordinationestablishes a

framework thatintroduces ageneric servicebased on thecoordinator servicemodel

This service controls a composition of three other services that each

play a specific part in the management of context data.


36/122

Services of Coordinator

Composition Activation serviceActivation service

Responsible for the creation of a new context and forassociating this context to a particular activity.

Registration serviceRegistration service

information received from the activation service toregister for a supported context protocol.

ProtocolProtocol--specific servicesspecific services

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

Coordination serviceCoordination service. The controller service of this composition


37/122

Coordinator service


38/122

Coordination type Each coordinator is based on a coordination

type, which specifies the nature and underlyinglogic of an activity for which context informationis being managed.

The WS-Coordination framework is extensible

and can be utilized by different coordinationtypes. WS-AtomicTransaction WS-BusinessActivity

Coordination type extensions provide a set ofcoordination protocols


39/122

Coordination protocol The actual process that a coordinator uses to

communicate with an application is defined by

the coordination protocol chosen by theapplication. The coordination protocol defines a series of

messages between the coordinator and eachapplication that is participating in thecoordination.

In a single coordination, each participating Web

service application can request to use a differentprotocol when communicating with thecoordinator


40/122

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 SOAPmessage 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 thecoordination context has been defined for.

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

Other coordinationOther coordination--specific informationspecific information The Coordination-Contextelement is extensible and can be used to carry other application-specificinformation relating to the coordinated process.


41/122

Coordination Participants service that wants to take part in an activity

managed by WS-Coordination must request thecoordination 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 hasA service that has received a context and hascompleted registration is considered acompleted registration is considered a

participantparticipantin the coordinated activity.in the coordinated activity.

Th


42/122

The

instantiatedprocess

The coordinationservice com osition is

Via aCreateCoordinationCo

This invitationconsists of the

context informationthe applicationservice originallyreceived from theactivation service.

Any Web servicein possession of

this contextinformation mayissue are istration

Upon asuccessfulregistration, aservice is officiallya participant. The

registrationservice passesthe service thelocation of theinstantiated when anapplication servicecontacts the activationservice

message, it asks theactivation service togenerate a set of newcontext data. Oncepassed back with the

ReturnContextmessage, theapplication servicenow can invite otherservices to participate

in the coordination.

request to theregistrationservice. Thisallows the serviceto enlist in a

coordinationbased on aspecific protocol.

coordinator

service, withwhich allparticipants arerequired tointeract.

The completion


43/122

The completion

process

The application service

can request that acoordination becompleted by issuing acompletion requestmessage to the

coordination service.The coordinator, in turn,then issues its owncompletion requestmessages to all coordinationparticipants. Each

participant service respondswith a completionacknowledgement message


44/122

Coordination and SOA

Case Study 4 3 1


45/122

Case Study 4.3.1

In the previous case study example, we established the individual

process steps that comprised a complex activity. Once the processingof this activity enters the TLS environment, TLS employs a contextmanagement system to coordinate the flow of the message through itsinternal services.

As shown in Figure coordination is applied to the following steps:3. The Accounts Payable Service uses the Vendor Profile Service to validate theinvoice 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 theinvoice document. These values, along with the invoice total, are submitted tothe 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


46/122

A message construct used to request thecreation of a context

http://www.examples.ws/activation

The ActivationService elementdefines the address of theservice that will create (activate)the context.

The RequesterReferenceelement contains the address towhich the response message

http://www.xmltc.com

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

should be sent.

The CoordinationTypeconstruct indicates which type ofcoordinator we would like tocreate. The use of the

http://schemas.xmlsoap.org/ws/2002/08/wstx URI ndicates thatwe are requesting an atomictransaction coordination type, asspecified in the WS-Transaction

specification.


47/122

Key Points 4.3 Complex activities tend to introduce the requirement for

context data and the subsequent need for this data to bemanaged and coordinated at runtime.

WS-Coordination provides a context management

headed by a coordinator service. Specialized implementations of this framework are

realized through the use of coordination types, such asWS-AtomicTransaction and WS-BusinessActivity.

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


48/122

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


49/122

Transaction Termine generico che si riferisce ad ogni attivit

che crea, aggiorna o cancella i dati in undatabase Quando un set ordinato di operazioni

modulato come una transazione allora tuttolinsieme 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


50/122

ACID In generale le propriet delle transazioni

sono conosciute come propriet ACID,

ossia che assicurano Atomicit,Consistenza, Isolamento e Persistenza

. Ad esempio un sistema di gestione di basi di

dati, conduce le transazioni in modo dagarantire la consistenza dei data recordsanche quando vengono eseguite pioperazioni in concorrenza su di essi.

ACID properties of data


51/122

ACID properties of data AtomicAtomic

Latomicit rappresenta il fatto che la transazione ununita indivisibile diesecuzione; o vengono resi visibili tutti gli effetti di una transazione, oppure latransazione non deve avere alcun effetto. Viene quindi seguito un approcciotutto 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.

IsolatedIsolated richiede che lesecuzione di una transazione sia completamente indipendente

dalla contemporanea esecuzione di altre transazioni. In un ambiente distribuitolisolamento nasconde anche gli stati intermedi di una transazioni rendendoliinaccessibili dallesterno.

DurableDurable

richiede che leffetto di una transazione che abbia eseguito il commitcorrettamente non venga pi perso.

Distributed Transaction


52/122

Distributed Transaction

ACID Properties Recover

Move money transaction

DepositTransaction

WithdrawTransaction

Per applicazioni distribuite si ha lanecessit di mettere insiemetransazioni costituite esse stesse datransazioni

Atomicity anddurability

Concurrency control Consistency and

isolation

DB1 DB2


53/122

Two-Phase Commit (2PC) protocol

Assicura latomicit nelle transazioni

distribuite Il modello per ciascuna sottotransazione

Ciascuna transazione 2PC richiede uncoordinatore che corrisponde alla main

transaction

Business Transaction


54/122

Business Transaction

Con il termine Business Transaction siindica un cambiamento consistente nello

stato di un processo condotto tra diverseorganizzazioni

complessi non pu essere realizzataadeguatamente con gli attuali sistemi discambi di messaggi

BT Framework


55/122

BT Framework

Apposito framework che assicuri che letransazioni che costituiscono il processo sianocondotte secondo specifiche regole:

strumenti per definire la logica di business formato e sequenza di messaggi necessari per

La sincronizzazione delle attivit che vengonosvolte allinterno dei singoli partecipanti alprocesso deve essere gestita tenendo conto

della natura dello scenario dove avviene lacomunicazione (ad esempio il Web);


56/122

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 (coordinationset di protocolli di coordinamento (coordination

protocols)protocols) che permettano di gestire le operazionieseguite dai vari e-Services e creare il contestonecessario per propagare dati e informazioni tra questi.

Un supporto per protocolli di business (businesssupporto per protocolli di business (businessprotocolsprotocols), e cio protocolli che definiscano lordine con

cui i partner si scambiano messaggi e che colgano ognialtro aspetto comportamentale del processo.

BT a breve e a lungo termine


57/122

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

e a reve erm ne possono essere ann a e man enen o u e e

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 ilrisultato finale della BT dipende dalla particolare logica o da unadecisione esplicita del cliente che ha iniziato la transazione.


58/122

Breve termine vs lungo termine Quando si sta eseguendo una transazione tra

diversi partner ci saranno alcune operazioni cheognuno di questi pu svolgereindipendentemente, e ce ne saranno altre che

Tutto ci che riguarda una sola organizzazionegeneralmente viene svolto in una transazioneatomica mentre le transazioni a lungo termine si

rendono pi adatte per gestire le interazioni congli altri partecipanti, specialmente quando sidevono prendere decisioni che non possonoessere automatizzate.


59/122

Soluzioni per il lungo termine Rilascio della rigidit delle propriet ACID

Attivazione di un meccanismo dicompensazione

BUSINESS ACTIVITIESBUSINESS ACTIVITIES Quando si eseguono short duration

transactions e si deve preservare in thestrict sense the ACID properties ATOMIC TRANSACTIONSATOMIC TRANSACTIONS


60/122

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


61/122

g p p 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 bucketneeds to be reset to its original state (empty).

This requirement emulates an atomic transaction,

where at the completion of Step 5, the process is eitherrolled back to the beginning of Step 4, or the quality ofwater is accepted (committed) so that it can be appliedto washing the car.

Two-Phase Commit


62/122

Main protocol used for completing transactionswhile maintaining the ACID properties of data

AtomicTransaction specifies two versions of thetwo-phase commit protocol, known as volatile anddurable. The volatile two-phase commit protocol is used for

coordinating volatile resources, such as an in-memorycache,

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


63/122

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


64/122

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


65/122

The atomic transaction coordinator

This particularimplementation of the

WS-Coordinationcoordinator servicerepresents a specificservice model.

The atomictransactioncoordinator plays akey role in managingthe participants of the

transaction processand in deciding thetransaction's ultimateoutcome

The atomic transaction process


66/122

The atomic transaction process

the atomic transaction coordinator is

tasked with the responsibility of decidingthe outcome of a transaction.

receives from all of the transactionparticipants.

The collection of this feedback isseparated into more phases

the prepare phase


67/122

the preparephase 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


68/122

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 PhaseNo re ie s all otes and decides hether to commit or rollback the


69/122

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, thecoordinator declares the transaction successful, and the changes arecommitted.

However, if any one vote requests an abort, or if any of the participantsfail to respond, then the transaction is aborted, and all changes arerolled back

Examples of a Coordinated


70/122

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 coordinator service that acts as both the activation service and the registrationservice for the coordination

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

This means that if either MyShippingService or MyInventoryService shouldfail, the entire transaction cannot succeed.

example


71/122

1. After receiving a customer order, MyOrderService sends aCreateCoordinationContext message to MyCoordinator to request a newcoordination context for the transaction.

2. MyCoordinator returns a CreateCoordinationContextResponse messagecontaining 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)


72/122

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

6. MyInventoryService sends a Register message to the registration service to enterinto 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 aCoordinationContext header element with the context identifier and the address of theregistration service.



73/122

9. MyShippingService sends a Register message to the registrationservice to enter into the existing coordination context, requesting touse 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 andMyInventoryService to begin the two-phase commit process. SinceMyShippingService isn't using two-phase commit, it doesn't receivethe Prepare message



74/122

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

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

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

Key Points


75/122

Key Points

WS-AtomicTransaction is a coordinationtype that supplies five coordinationprotocols that can be used to achieve two-phase commit transactions across multipleservice participants.

The atomic transaction coordinator makesthe ultimate decision to commit or rollback

a transaction. This decision is based onvotes collected from participants.

Final Considerations


76/122

1. Il punto fondamentale di questo protocollo quindi ilblocco delle risorse finch non si sicuri che tutto siastato eseguito correttamente. Questa pratica non adatta in ambiente Web.

1. In primo luogo il Web caratterizzato da comunicazioniasincrone e non affidabili ; questo ostacola limplementazionedi un protocollo 2PC in quanto il coordinatore non pu esserecerto del tempo impiegato da un partecipante a rispondere aisuoi messaggi di prepare e di commit e rischia di attendere

indefinitamente.2. Anche luso di timeout per ovviare a questo problema non offreuna valida soluzione perch timeout troppo corti possonocausare labort di un numero eccessivo di transazioni cheinvece sarebbero andate a buon fine, mentre timeout troppo

lunghi possono tenere molte risorse bloccate inutilmente pertempi inaccettabili.

Final Considerations


77/122

2. Secondariamente bisogna considerare cheunorganizzazione che partecipi ad una transazionedifficilmente sarebbe disposta a bloccare le proprierisorse per lungo tempo.

1. principalmente per questi motivi che si ormai diffusa lideadi rilassare i vincoli imposti dalle propriet ACID quando si ha

pi organizzazioni diverse.2. Data la loro natura, le BT a breve termine possono essere

implementate secondo i classici protocolli 2PC. Tipicamenteinfatti le operazioni di una BT a breve termine sono

completamente automatizzate (e quindi eseguite in tempibrevissimi) e non escono dai confini di unorganizzazione.

BT a lungo termine


78/122

Viene considerata come un insieme ditransazioni a breve termine. Il coordinatore fa in modo che ognuna di queste

venga eseguita indipendentemente dalle altre eraccoglie i vari esiti che gli giungeranno indiversi istanti di tempo. Generalmente alcuni

.

A seconda di quali transazioni sono andate abuon fine e quali no, verr presa una decisione(da una specifica applicazione di business o

direttamente dal cliente) sullesito globale dellaBT.

Not offer rollback capabilities


79/122

p

COMPENSATION PROCESSCOMPENSATION PROCESS

Business activity protocols


80/122

y p

TheBusinessAgreementWithParticipantCompletionprotocol, which allows a participant todetermine when it has completed its part in thebusiness activity.

TheBusinessAgreementWithCoordinatorCompletionprotocol, which requires that a participant relyon coordinator to notify it that it has no furtherprocessing responsibilities.

Business activity coordinator


81/122

y

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


82/122

gback automatico, ma per una BT occorre iniziare delle transazioni dicompensazione che svolgano le operazioni inverse di quelle fatte datutte le transazioni che inizialmente avevano eseguito il commit.

Questo approccio, noto come backward recovery, non semprepossibile poich pu capitare che alcune operazioni sianoirreversibili.

In questo caso si deve procede secondo un altro approccio (forward

recovery) che d il via a nuove transazioni le quali, preso atto deicambiamenti ormai avvenuti, riconducono il processo ad uno statosimile 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, bisognacomunque far fronte alle spese di spedizione e di conseguenza lo statofinale non potr mai essere uguale a quello di partenza..

Business activity states


83/122

During the lifecycle of a business activity, thecoordinator and the participants transitionthrough a series of states.

The actual point of transition occurs whenspecial notification messages are passed

States are defined in a series of state tablesdocumented as part of the WS-BusinessActivityspecification.

These tables establish the fundamental rules ofthe business activity protocols by determiningthe sequence and conditions of allowable states.

State example


84/122

Active State Completed state

For example, a participant can indicate that it has completed theprocessing it was required to perform as part of the activity byissuing a completed notification. This moves the participant from

.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 theyattempt to perform some measure of exception handling. This

generally invokes a separate compensation process that couldinvolve a series of additional processing steps.

State example


85/122

Cancelled state Alternatively to compensation state; this typically results in the

termination of any further processing outside of the cancellationnotifications that need to be distributed

Exit state

transactions is the fact that participating services are notrequired to remain participants for the duration of the activity.Because there is no tight control over the changes performed byservices, they may leave the business activity after theirindividual contributions have been performed. When doing so,

participants enter an exit state by issuing an exit notificationmessage to the business activity coordinator.

Business activity and atomic


86/122

transactions

Key Points


87/122

Business activities manage complex, long-running activitiesthat can vary in scope and in the amount of participatingservices.

WS-BusinessActivity builds on the WS-Coordination contextmanagement framework by providing two protocols forwhich activity participants can register.

Participants and the business activity coordinator progressthrough a series of states during the lifespan of a businessactivity. State transition is accomplished through theexchange of notification messages.

Web Service Transaction Summary


88/122

WS-Atomic Transaction and WS-

BusinessActivity leverage WS-Coordination

definendo due tipi di coordinamento :

Short term atomic transaction

Long duration business activity

ORCHESTRATION


89/122

With orchestration, different processes can beconnected without having to redevelop the

solutions that originally automated theprocesses individually. Orchestration bridges this gap by introducing

new workflow logic.

Further, the use of orchestration can significantlyreduce the complexity of solution environments.

Workflow logic is abstracted and more easily

maintained than when embedded withinindividual solution components.

Orchestration Control


90/122

Language specification


91/122

A primary industry specification that

standardizes orchestration is the WebServices Business Process Execution- .

WS-BPEL is the most recent name givento this specification, which also is knownas BPEL4WSand just BPEL.

Business protocols and process


92/122

definition The workflow logic that comprises anorchestration can consist of numerous business

rules, conditions, and events. Collectively, these parts of an orchestration

participants can interoperate to achieve thecompletion of a business task. The details of the workflow logic encapsulated

and expressed by an orchestration arecontained within a process definitionprocess definition.

Process services and partner

i


93/122

services First, the process

itself is representedas a service, resultingin a process service

Other servicesallowed to interactwith the processservice are identifiedas partner servicesorpartner links

Basic activities and structured

i i i


94/122

activities WS-BPEL breaks down workflow logic into

a series of predefined primitive activities. Basic activities(receive, invoke, reply,,

workflow actions which can be assembledusing the logic supplied by structuredactivities(sequence, switch, while, flow,pick).

Some activities


95/122

Sequence aligns groups of related activities into a list that

determines a sequential execution order. Flows

,

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 requirementsestablished in outgoing links first are met.

Orchestration and coordination


96/122

Orchestration, as represented by WS-BPEL, can

fully utilize the WS-Coordination contextm n m n fr m w rk in r r in h

WS-BusinessActivity coordination type.

Key Points


97/122

An orchestration expresses a body of business processlogic that is typically owned by a single organization.

An orchestration establishes a business protocol thatformally defines a business process definition.

The workflow logic within an orchestration is broken

down into a series of basic and structured activities thatcan be organized into sequences and flows.

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

establishes a means of centralizing and controlling agreat deal of inter and intra-application logic through astandardized service model.

Choreography


98/122

A choreography is essentially a collaborationprocess designed to allow organizations to

interact in an environment that is not owned byany one partner.

Language (WS-CDL) is one of severalspecifications that attempts to organizeinformation exchange between multipleorganizations (or even multiple applicationswithin organizations), with an emphasis onpublic collaboration

A choreography enables collaboration

between its participants


99/122

between its participants.

Choreography elements


100/122

Roles

This establishes what the service does Relationship

Each potential exchange between two roles Channels

defining the characteristics of the messageexchange between two specific roles

Interactions and work units


101/122

Interactions are the fundamental buildingblocks of choreographies. the completion of an interaction represents

.

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


102/122

While both represent complex message interchangepatterns, there is a common distinction that separatesthe terms "orchestration" and "choreography."

An orchestration expresses organization-specificbusiness workflow. This means that an organization owns and controls the logic

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

The choreography acts as a community interchangepattern used for collaborative purposes by services from

different provider entities A choreography, on the other hand, is not necessarily owned bya single entity.

A choreography enabling collaboration

between two different orchestrations


103/122

between two different orchestrations

Orchestrations and choreographies


104/122

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

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

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

A choreography typically assumes that there is no singleowner of collaboration logic.

Web ServicesOrchestration

Execution order of webservices interactions

Web ServicesChoreography

Tracks the sequence ofmessages involving multiple


105/122

Describes process flow Includes internal and external

webservices Process is always controlled byone party

g g pparties and sources

Public message exchanges, notexecutable processes

Collaborative - no singlecontroller

web

service

webservice

webservice

webservice

web

service

web

service

Collaboration

Process flow

Example of Web Services

Composition


106/122

Composition

Orchestration-Centric Approach


107/122

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 pickend while

invoke OpenAccount

invoke SendConfirmation

Choreography-Centric Approach

C ll tA tI f ti d


108/122

CollectAccountInformation and

ValidateAccountInformation

ValidateAccountInformation and

RepairAccountInformation.

ValidateAccountInformation and

OpenAccount.

OpenAccount and

SendConfirmation.

RepairAccountInformation and

DeclineAccountApplication

Comparing Orchestration-Centric andChoreography-Centric Approaches

I l h h h i h i


109/122

In general, the choreography-centric approach is moreloosely coupled. It is particularly well suited when portions of the process span

administrative and organizational boundaries, which makes itdifficult (if not impossible) to synchronize internal processes;however it is much more im ortant to define and s ecif thebusiness protocol linking the partners (even if the "partners" are

simply departments in the same company). One key difference is that the orchestration approachassumes a single, central point of control over the entirescope of the process execution, while the choreography

approach assumes that execution control is shared,potentially across multiple business process engines orvarious other technologies.

KEY POINTS


110/122

A choreography is a complex activitycomprised of a service composition and aseries of MEPs.

participants that can assume differentroles and that have different relationships. Choreographies are reusable,

composable, and can be modularized.


111/122

Request-Response MEP


112/122

SOAP Response MEP


113/122

LIFE CYCLE di una transazione che pupartecipare come sottotransazione in 2PC


114/122

initialized computing precommitteddone

Ciascuna TR appena partitaentra in uno stato in cui eseguela sua local computation

aborted

Internal

error failure committed

forgotten

ESEMPIO di ESECUZIONE di una PC


115/122

SubTR1SubTR1 CoordinatorCoordinator SubTR2SubTR2

register re ister

Quando ilcoordinatoreparte registra lesottotransazioni

vote vote

decision decision

Se si halunanimit dicommit allora ilcoordinatore

annuncia unacommit decisionealtrimenti un abortdecision (rollback)

Ogni partecipante pu aggiornare il suo

stato dopo ciascun passo della


116/122

p p

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 difallimento fa perdere semanticamente glieffetti dellesecuzione parziale della


117/122

transazione

Ciascuna operazione pu avere unadifferente logica di compensazione

Ciascun provider pu avere una differenteopinione riguardo lesatto significato dicompensare una operazione

Disdetta reservation con pagamento penale ono

Short term atomic transaction

(example) Travel agency deve trovare un volo per un


118/122

( p ) Travel agency deve trovare un volo per uncliente che deve visitare un museo

Travel Agency e Airline hanno i propri

service)

Travel AgencyServer

WS

Airline Server

WS

Museum Server

(1) commit (3)prepare(4) prepare (5)prepared


119/122

COORD. COORD.WS (2)prepare

(6)prepared

p p

(7)message

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 protocol3. I servizi coinvolti si dichiarano pronti ad eccezione del museo che risponde

con un messaggio ed abbandona la transazione

Travel Agency Server

WS

Airline Server

WS


120/122

WS WS

(9) vote (10) voted(12) voted

COORD.COORD.

Notifica del voto e votazione

(8) vote

(11) voted

Business Activity example

Tre web services (A B C) con un


121/122

Tre web services (A B C) con uncoordinatore R

A inizia il protocollo mentre B e C vi


122/122

A inizia la Business Activity e passa il contesto a B e C che si registrano conR per il BusinessAgreement ProtocolB finisce il suo lavoro mentre C incontra un erroreSe 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

contemporary soa - i

Documents