Post on 02-Apr-2018
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
7/27/2019 Contemporary SOA - I
2/122
1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGE1. MESSAGE EXCHANGEPATTERNSPATTERNSPATTERNSPATTERNSPATTERNSPATTERNSPATTERNSPATTERNS
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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).
7/27/2019 Contemporary SOA - I
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/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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
, - - -
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
14/122
WS-* specification the incorporate this
messaging model include: WS-BaseNotification - WS-Topics WS-Eventing
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
16/122
WSDL support : Request-responseoperation
Upon receiving a message, the service
must respond with a standard message ora fault message.
7/27/2019 Contemporary SOA - I
17/122
WSDL support : Solicit-responseoperation
Upon submitting a message to a service
requestor, the service expects a standardresponse message or a fault message.
7/27/2019 Contemporary SOA - I
18/122
WSDL support : One-way operation The service expects a single message and
is not obligated to respond.
7/27/2019 Contemporary SOA - I
19/122
WSDL support : Notificationoperation
The service sends a message and expects
no response.
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
23/122
2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY2. SERVICE ACTIVITY
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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-
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
29/122
7/27/2019 Contemporary SOA - I
30/122
3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION3. COORDINATION
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
32/122
Coordination framework
provide a meansfor contextinformation incomplex activitiesto be managed,
preserved and/orupdated, anddistributed toactivity
participants.
7/27/2019 Contemporary SOA - I
33/122
Example
7/27/2019 Contemporary SOA - I
34/122
Car wash simple task
chuck
Collect Equipment
bob
jim
Prepare Water
Wash the car
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
37/122
Coordinator service
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
44/122
Coordination and SOA
Case Study 4 3 1
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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)
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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);
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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)
7/27/2019 Contemporary SOA - I
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.
Steps for example (2)
7/27/2019 Contemporary SOA - I
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
Steps for example (3)
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
79/122
p
COMPENSATION PROCESSCOMPENSATION PROCESS
Business activity protocols
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
81/122
y
Abort di una BT e compensazione Quando una transazione atomica fallisce viene garantito un roll-
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
86/122
transactions
Key Points
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
90/122
Language specification
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - 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
7/27/2019 Contemporary SOA - 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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
99/122
between its participants.
Choreography elements
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
103/122
between two different orchestrations
Orchestrations and choreographies
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
106/122
Composition
Orchestration-Centric Approach
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - 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
7/27/2019 Contemporary SOA - I
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.
7/27/2019 Contemporary SOA - I
111/122
Request-Response MEP
7/27/2019 Contemporary SOA - I
112/122
SOAP Response MEP
7/27/2019 Contemporary SOA - I
113/122
LIFE CYCLE di una transazione che pupartecipare come sottotransazione in 2PC
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
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
7/27/2019 Contemporary SOA - I
121/122
Tre web services (A B C) con uncoordinatore R
A inizia il protocollo mentre B e C vi
7/27/2019 Contemporary SOA - I
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