Transcript WS-* and contemporary SOA

PART IV - contemporary SOA
Activity Management and
Composition
1. Message Exchange
Patterns
Message Exchange Consideration
• Every task automated by a Web service can
differ
– nature of the application logic being executed
– the role played by the service
• Regardless of how complex a task is, almost all
require the transmission of multiple messages.
• The challenge lies in coordinating these
messages in a particular sequence so that the
individual actions performed by the message are
executed properly and in alignment with the
overall business task
MEP
• Message exchange pattern (MEP) is a template that
establishes a pattern for the exchange of messages
between SOAP nodes.
– Generalized to Web services, a message exchange pattern
is a template that establishes a pattern for the exchange of
messages between two communicating parties.
• MEP definitions will therefore be used by several
technologies in the Web services architecture:
– communication protocols such as SOAP
– description languages such as WSDL
Primitive MEPs: Request-response
• The request-response MEP establishes a simple
exchange in which a message is first transmitted
from a source (service requestor) to a
destination (service provider). Upon receiving
the message, the destination (service provider)
then responds with a message back to the
source (service requestor).
Case Study 4.1.1
In the Service compositions
section, we provided an
example where the TLS
Accounts Payable Service,
upon receiving an invoice
submission from a vendor,
enlists the TLS Vendor
Profile Service to validate the
invoice header information.
Case Study 4.1.1 [segue]
The MEP used in this situation is the standard request-response
pattern, where a response from the Vendor Profile Service is
expected once it receives and processes the original request. The
Accounts Payable Service requires a response to ensure that the
header details provided in the invoice submission are valid and
current
Failure to validate this information terminates the Invoice
Submission Process and results in the Accounts Payable Service
responding to the vendor with a rejection message.
Primitive MEPs: fire-and-forget
• This simple asynchronous pattern is based
on the unidirectional transmission of
messages from a source to one or more
destinations
Fire-and-forget MEP variations
1. The single-destination pattern, where a source
sends a message to one destination only.
2. The multi-cast pattern, where a source sends
messages to a predefined set of destinations.
3. The broadcast pattern, which is similar to the
multi-cast pattern, except that the message is
sent out to a broader range of recipient
destinations.
Case Study 4.1.2
The TLS Accounts Payable Service contains a rule that when an invoice
header fails validation, an e-mail notification is generated. To execute this
step, the Accounts Payable Service sends a message to the Notification
Service. This utility service records the message details in a notification
log database. (These records are used as the basis for e-mail
notifications, as explained in the next example.) Because the message
sent from the Accounts Payable Service to the Notification Service
requires no response, it uses a single-destination fire-and-forget MEP
Complex MEPs
• Primitive MEPs can be assembled in
various configurations to create different
types of messaging models, sometimes
called complex MEPs.
• A classic example is the publish-andsubscribe model
The publish-and-subscribe messaging
model is a composite of two primitive MEPs
• Step 1 could be implemented by a
request-response MEP, where the
subscriber's request message,
indicating that it wants to
subscribe to a topic, is responded
to by a message from the
publisher, confirming that the
subscription succeeded or failed.
• Step 2 then could be supported by
one of the fire-and-forget patterns,
allowing the publisher to
broadcast a series of
unidirectional messages to
subscribers.
Case Study 4.1.3
The utility Notification Service periodically generates and distributes
notification messages for a number of different topics. Messages from
outside vendors that fail validation, for example, are first logged in a
dedicated notification repository. At the end of every working day, the
Notification Service queries this repository to retrieve all failed
submissions.
It then summarizes specific pieces of information from the query
results and uses this data to populate a broadcast notification
message. This message is subsequently sent to a list of subscribers
consisting primarily of specialized accounting services .
These services record the notification data into various profile and
account records. Some pass the notification on as an e-mail to select
accounting personnel.
MEPs and WSDL
• MEPs play a larger role in WSDL service
descriptions as they can coordinate the input
and output messages associated with an
operation. ( esempio )
• WSDL defines several combination of input and
output as part of a PortType description:
– Input-Output Operations.
– Input-Only Operations.
– Output-Input Operations.
– Output-Only Operations.
WSDL support : Request-response
operation
• Upon receiving a message, the service
must respond with a standard message or
a fault message.
WSDL support : Solicit-response
operation
• Upon submitting a message to a service
requestor, the service expects a standard
response message or a fault message.
WSDL support : One-way operation
• The service expects a single message and
is not obligated to respond.
WSDL support : Notification
operation
• The service sends a message and expects
no response.
Punti Chiave 4.1
• An MEP is a generic interaction pattern that defines the
message exchange between two services.
• MEPs can be composed to support the creation of larger,
more complex patterns.
• The WSDL specifications support specific variations of
common MEPs.
2. Service ACTIVITY
Service activity
– In service-oriented solutions, each task can
involve any number of services.
• The interaction of a group of services
working together to complete a task can
be referred to as a service activity
Simple or primitive activity
• A simple or primitive activity is typified by
synchronous communication and therefore
often consists of two services exchanging
information using a standard requestresponse MEP
Complex activities
• Complex activities, on the other hand, can
involve many services (and MEPs) that
collaborate to complete multiple processing
steps over a long period of time
Service Activity and SOA
• Activities represent any service
interaction required to complete
business tasks.
• The scope of a service activity is primarily
concerned with the processing and
communication between services only
Case Study 4.2.1
1. The initial sender, RailCo's Invoice Submission Service, transmits the invoice message
2. The message is first received by a passive intermediary, which routes the message according
to
conditions.
The message
Accounts
Payable
Service
3. environmental
The Accounts Payable
Service
acts as a subsequently
controller andarrives
initiatesataTLS's
service
composition
to begin
processing the message contents. It begins by interacting with the Vendor Profile Service to
validate
header
dataService
and attaches
the invoice
document
the and
vendor
4. The invoice
Accounts
Payable
then extracts
taxes,
shipping to
fees,
the account.
invoice total.
It passes these values to the Ledger Service, which updates various ledger accounts,
including
the General
Ledger
5. Finally
the activity
ends, as the Accounts Payable Service completes
its processing cycle by sending a response message back to RailCo
Punti Chiave 4.2
• An activity is a generic concept used to represent a task
or a unit of work performed by a set of services.
• The scope of primitive activities can be limited to the
completion of simple MEPs.
• Complex activities are common within SOAs and exist as
part of any non-trivial service-oriented application
3. COORDINATION
COORDINATION
• Every activity introduces a level of context into an
application runtime environment.
– Something that is happening or executing has meaning during its
lifetime, and the description of its meaning (and other
characteristics that relate to its existence) can be classified as
context information.
• The more complex an activity, the more context
information it tends to bring with it.
• The complexity of an activity can relate to a number of
factors, including:
–
–
–
–
the amount of services that participate in the activity
the duration of the activity
the frequency with which the nature of the activity changes
whether or not multiple instances of the activity can concurrently
exist
Coordination framework
• provide a means
for context
information in
complex activities
to be managed,
preserved and/or
updated, and
distributed to
activity
participants.
Example
Car wash simple task
Collect Equipment
chuck
bob
Prepare Water
Wash the car
jim
Car wash steps
Locate bucket. - Locate sponge.
Locate hose
I
chuck
II
II
chuck
bob
III
bob
III
jim
jim
Car wash considerations
•
•
•
•
In this scenario, the bucket availability status is considered context
information that I managed.
Because a separate context manager was in place, Chuck was alleviated
of the responsibility of remembering and communicating the context
information to Bob.
This liberate Chuck to continue with his other work.
It also saved Bob from having to directly locate and communicate with
Chuck to get the context information.
• Finally, my knowledge of who was doing what in this
car washing process also would be classified as
context information.
Coordinator service model
WS-Coordination
establishes a
framework that
introduces a
generic service
based on the
coordinator service
model
This service controls a composition of three other services that each
play a specific part in the management of context data.
Coordinator service
Protocol-specific
services
Activation service
These
servicesfor the
Responsible
represent
thea new
creation of
protocols
supported
context and
for
byassociating
the coordinator's
this context
coordination
type.
to a particular
activity
Registration service
Allows participating services to
use context information
received from the activation
service to register for a
supported
context protocol
Coordination
service.
The controller service of this
composition
In poche parole …..
Coordination type
• Each coordinator is based on a coordination
type, which specifies the nature and underlying
logic of an activity for which context information
is being managed.
• The WS-Coordination framework can be utilized
by different coordination types.
– WS-AtomicTransaction
– WS-BusinessActivity
• Coordination type extensions provide a set of
coordination protocols
Coordination protocol
• The actual process that a coordinator uses
to communicate with an application is
defined by the coordination protocol
chosen by the application.
• The coordination protocol defines a series
of messages between the coordinator and
each application that is participating in the
coordination.
• In a single coordination, each participating
Web service application can request to
use a different protocol when
communicating with the coordinator
Coordination Context
• A context created by the activation service is referred to as a
coordination context
• The coordination context contains all of the coordination-related
information for a coordinated process and is defined in a SOAP
message by the CoordinationContext element in the SOAP
message header.
• can contain the following information:
– Expiration value
– Identifier (unique) that represents the activity
– Coordination type Defines the type of coordination process that the
coordination context has been defined for.
– Registration service Address of the service from which another Web
service can request entry into the coordinated process.
– Other coordination-specific information The Coordination-Context
element is extensible and can be used to carry other application-specific
information relating to the coordinated process.
Coordination Partecipants
• service that wants to take part in an activity
managed by WS-Coordination must request the
coordination context from the activation service.
• It then can use this context information to
register for one or more coordination protocols.
• A service that has received a context and has
completed registration is considered a
participant in the coordinated activity.
The
instantiated
process
This invitation
consists of the
context
information
Upon
a
the application
successful
service originally
registration,
a
received
from the
service
is officially
Any
Web
service
service.
a participant.
The
inactivation
possession
of
registration
this context
service
information
Via
a passesmay
the
service
The
coordination
issue
a the
CreateCoordinationCo
location
of
the
service
composition
is
registration
ntext
request
coordinator
instantiated
an
request to
the the
message,
it when
asks
service,
with
application
serviceto
registration
activation
service
which
all the
contacts
activation
service.
generate
aThis
set
of new
participants
are
service
allowsdata.
the service
context
Once
required
to
to enlist
in awith the
passed
back
interact.
coordination
ReturnContext
based onthe
a
message,
specific protocol.
application
service
now can invite other
services to participate
in the coordination.
The completion
process
The application service
can request that a
coordination be
completed by issuing a
completion request
message to the
The
coordinator,
in turn,
coordination
service.
then issues its own
completion request
messages to all coordination
participants. Each
participant service responds
with a completion
acknowledgement message
Coordination and SOA
Case Study 4.3.1
As shown in Figure coordination is applied to the following steps:
3. The Accounts Payable Service uses the Vendor Profile Service to validate the
In theheader
previous
case
study
example,
the individual
invoice
data.
If the
data
is valid, we
the established
invoice document
is attached to the
process
steps that comprised a complex activity. Once the processing
vendor
account.
of this activity enters the TLS environment, TLS employs a context
management
coordinate
the flow
ofand
the shipping
messagefees
through
4. The
Accounts system
PayabletoService
extracts
taxes
fromits
the
internal
services.These values, along with the invoice total, are submitted to
invoice
document.
the Ledger Service. The Ledger Service is responsible for updating the General
Ledger and numerous sub-ledgers, such as the Accounts Payable Ledger.
A message construct used to request the
creation of a context
<CreateCoordinationContext>
<ActivationService>
<wsu:Address>
http://www.examples.ws/activation
</wsu:Address>
</ActivationService>
<RequesterReference>
<wsu:Address>
http://www.xmltc.com
</wsu:Address>
</RequesterReference>
<CoordinationType>
http://schemas.xmlsoap.org/ws/2002/08/wstx
</CoordinationType>
</CreateCoordinationContext>
The ActivationService element
defines the address of the
service that will create (activate)
the context.
The RequesterReference
element contains the address to
which the response message
should be sent.
The CoordinationType
construct indicates which type of
coordinator we would like to
create. The use of the
http://schemas.xmlsoap.org/ws/2
002/08/wstx URI ndicates that
we are requesting an atomic
transaction coordination type, as
specified in the WS-Transaction
specification.
Key Points 4.3
• Complex activities tend to introduce the requirement for
context data and the subsequent need for this data to be
managed and coordinated at runtime.
• WS-Coordination provides a context management
framework using a standardized service composition
headed by a coordinator service.
• Specialized implementations of this framework are
realized through the use of coordination types, such as
WS-AtomicTransaction and WS-BusinessActivity.
• By introducing an activity management layer to SOA,
coordination promotes service composability and
supports the controlled composition of complex activities
4. BUSINESS TRANSACTION (BT)
Transaction
• Termine generico che si riferisce ad ogni attività
che crea, aggiorna o cancella i dati in un
database
• Quando un set ordinato di operazioni è
“modulato” come una transazione allora tutto
l’insieme è visto come “one logic operation”
– Gli effetti della transazione si vedono quando questa
unica operazione logica si è conclusa con successo
– Se l’operazione fallisce allora non è successo niente
ACID
• In generale le proprietà delle transazioni
sono conosciute come proprietà ACID,
ossia che assicurano Atomicità,
Consistenza, Isolamento e Persistenza
(Durabilità).
– Ad esempio un sistema di gestione di basi di
dati, conduce le transazioni in modo da
garantire la consistenza dei “data records”
anche quando vengono eseguite più
operazioni in concorrenza su di essi.
ACID properties of data
•
Atomic
– L’atomicità rappresenta il fatto che la transazione è un’unita indivisibile di
esecuzione; o vengono resi visibili tutti gli effetti di una transazione, oppure la
transazione non deve avere alcun effetto. Viene quindi seguito un approccio
“tutto o niente” dove non è possibile lasciare la transazione in uno degli stati
intermedi attraversati durante l’elaborazione
•
Consistent
– richiede che al termine della transazione tutti i dati manipolati siano coerenti con
la semantica della transazione stabilita da una logica di business.
•
Isolated
– richiede che l’esecuzione di una transazione sia completamente indipendente
dalla contemporanea esecuzione di altre transazioni. In un ambiente distribuito
l’isolamento nasconde anche gli stati intermedi di una transazioni rendendoli
inaccessibili dall’esterno.
•
Durable
– richiede che l’effetto di una transazione che abbia eseguito il commit
correttamente non venga più perso.
Distributed Transaction
Move money transaction
Deposit
Transaction
Withdraw
Transaction
Per applicazioni distribuite si ha la
necessità di mettere insieme
transazioni costituite esse stesse da
transazioni
• ACID Properties
• Recovery
– Atomicity and
durability
DB1
DB2
• Concurrency control
– Consistency and
Isolation
Two-Phase Commit (2PC) protocol
• Assicura l’atomicità nelle transazioni
distribuite
• Il modello per ciascuna sottotransazione
consiste in un piccolo numero di stati
• Ciascuna transazione 2PC richiede un
coordinatore che corrisponde alla “main
transaction”
Business Transaction
• Con il termine Business Transaction si
indica un cambiamento consistente nello
stato di un processo condotto tra diverse
organizzazioni
• BT Framework ( regole di conduzione
delle transazioni che costituiscono il
processo ):
– strumenti per definire la logica di business
– formato e sequenza di messaggi necessari
per conseguire il risultato voluto
Un BTF deve fornire
• un business transaction model per definire transazioni
a lungo termine, transazioni a breve termine, gestione
delle eccezioni e meccanismi di compensazione.
• un set di protocolli di coordinamento (coordination
protocols) che permettano di gestire le operazioni
eseguite dai vari e-Services e creare il contesto
necessario per propagare dati e informazioni tra questi.
• Un supporto per protocolli di business (business
protocols), e cioè protocolli che definiscano l’ordine con
cui i partner si scambiano messaggi e che colgano ogni
altro aspetto comportamentale del processo.
BT a breve e a lungo termine
• Le BT a breve termine (o BT atomiche) sono costituite da
interazioni su scala ridotta che posso essere eseguite garantendo le
proprietà ACID in modo molto simile alle transazioni classiche.
– Una BT atomica vedrà come unico risultato o un commit o un abort;
– in caso di abort è garantito il ritorno allo stato iniziale o tramite roll-back
o tramite una compensazione completa.
– Le BT a breve termine possono essere annidate mantenendo tutte le
loro caratteristiche.
• Le BT a lungo termine (o semplicemente BT) possono essere viste
come un insieme di BT, legate da una logica di business.
– Le singole transazioni possono avere esiti diversi, nel qual caso il
risultato finale della BT dipende dalla particolare logica o da una
decisione esplicita del cliente che ha iniziato la transazione.
Breve termine vs lungo termine
• Quando si sta eseguendo una transazione tra
diversi partner ci saranno alcune operazioni che
ognuno di questi può svolgere
indipendentemente, e ce ne saranno altre che
richiedono il contributo di più parti coinvolte 
• Tutto ciò che riguarda una sola organizzazione
generalmente viene svolto in una transazione
atomica mentre le transazioni a lungo termine si
rendono più adatte per gestire le interazioni con
gli altri partecipanti, specialmente quando si
devono prendere decisioni che non possono
essere automatizzate.
Soluzioni per il lungo termine
• Rilascio della rigidità delle proprietà ACID
• Attivazione di un meccanismo di
compensazione
• Richiesta quindi di protocolli standard
– BUSINESS ACTIVITIES
• Quando si eseguono “short duration
transactions” e si deve preservare “in the
strict sense the ACID properties”
– ATOMIC TRANSACTIONS
ATOMIC TRANSACTION
• Atomic transactions implement the familiar
commit and rollback features to enable crossservice transaction support ( traditional twophase transaction protocol )
Washing process example
•
This change to our process affects the following two
steps:
4. Fill bucket with warm water.
5. Add soap to water.
•
•
•
Originally, these steps were simply performed in
sequence as a continuation of the overall process.
Now we have a requirement that dictates that should
the resulting soap mixture be unacceptable, the bucket
needs to be reset to its original state (empty).
This requirement emulates an atomic transaction,
where at the completion of Step 5, the process is either
rolled back to the beginning of Step 4, or the quality of
water is accepted (committed) so that it can be applied
to washing the car.
WS-AtomicTransaction
• used to coordinate activities having an "all or nothing"
property.
• require a high level of trust between participants and are
short in duration.
• Characteristics of this coordination activity:
– actions taken prior to commit are only tentative (i.e., not
persistent and not visible to other activities).
– When an application finishes, it requests the coordinator to
determine the outcome for the transaction. The coordinator
determines if there were any processing failures by asking the
participants to vote. If the participants all vote that they were able
to execute successfully, the coordinator commits all actions
taken. If a participant votes that it needs to abort or a participant
does not respond at all, the coordinator aborts all actions taken.
– Commit makes the tentative actions visible to other transactions.
– Abort makes the tentative actions appear as if the actions never
happened.
Two-Phase Commit
• Main protocol used for completing transactions
while maintaining the ACID properties of data
• AtomicTransaction specifies two versions of the
two-phase commit protocol, known as volatile and
durable.
– The volatile two-phase commit protocol is used for
coordinating volatile resources, such as an in-memory
cache,
– The durable two-phase commit protocol is used for
coordinating durable resources, such as a database,
from which recovery is possible.
Atomic Transaction Type : five protocols
•
Completion
– One participant (generally the application that created the
transaction) registers for the completion protocol, so that it can tell
the coordinator either to try to commit the transaction or force a
rollback. A status is returned to indicate the final transaction
outcome.
•
CompletionWithAck
– Same as Completion, but the coordinator must remember the
outcome until receipt of an acknowledgment notification.
•
2PC
Atomic Transaction Type : five protocols
•
PhaseZero:
– A participant that wants the coordinator to notify it just before the 2PC
protocol begins registers for this. A typical example is an application
that caches data and needs a notification to write outstanding
updates to a database. This is executed prior to the 2PC
•
OutcomeNotification:
– A transaction participant that wants to be notified of the commit-abort
decision registers for this. Applications use outcome notifications to
release resources or perform other actions after commit or abort of a
transaction.
The atomic transaction coordinator
• The atomic
transaction
coordinator plays a
key role in managing
the participants of the
transaction process
and in deciding the
transaction's ultimate
outcome
The atomic transaction process
• the atomic transaction coordinator is
tasked with the responsibility of deciding
the outcome of a transaction.
• It bases this decision on feedback it
receives from all of the transaction
participants.
• The collection of this feedback is
separated into more phases
the prepare phase
• Quando tutte le applicazioni sono state informate delle operazioni
da svolgere, il coordinatore invia un messaggio prepare.
• A fronte di questo comando, le applicazioni bloccano le risorse
coinvolte nella transazione ed eseguono le operazioni.
Vote phase
• Each participant's vote consists of either a "commit" or "abort"
request
• In base al risultato ottenuto comunicano al coordinatore la loro
capacità di eseguire correttamente il commit o meno
Commit Phase
• Now reviews all votes and decides whether to commit or rollback the
transaction.
• The conditions of a commit decision are simple:
– if all votes are received and if all participants voted to commit, the
coordinator declares the transaction successful, and the changes are
committed.
– However, if any one vote requests an abort, or if any of the participants
fail to respond, then the transaction is aborted, and all changes are
rolled back
Examples of a Coordinated
Process
•
A single coordinator service manages an atomic transaction among three
Web services.
•
The Web services involved in this transaction are as follows:
– An order service that receives orders for products
– An inventory service that provides inventory information from a warehouse
– A shipping service that schedules shipments
– A coordinator service that acts as both the activation service and the registration
service for the coordination
•
For the MyOrderService application to successfully place an order, it needs
to verify both that the inventory for the product is available and that the
shipment can be arranged.
•
This means that if either MyShippingService or MyInventoryService should
fail, the entire transaction cannot succeed.
example
1. After receiving a customer order, MyOrderService sends a
CreateCoordinationContext message to MyCoordinator to request a new
coordination context for the transaction.
2. MyCoordinator returns a CreateCoordinationContextResponse message
containing the coordination context.
3. MyOrderService sends a Register request to the registration service,
requesting to use the two-phase commit protocol.
4. The registration service returns a RegisterResponse message.
Steps for example (1)
5. MyOrderService sends an inventory request message to MyInventoryService to
check the inventory and mark the requested number of units for shipment. In the
header of this message is a CoordinationContext header element with the context
identifier and the address of the registration service.
6. MyInventoryService sends a Register message to the registration service to enter
into the existing coordination context, also using the two-phase commit protocol.
7. The registration service returns a RegisterResponse message.
8. MyInventoryService sends a shipping request message to MyShippingService to
schedule and confirm delivery. In the header of this message is a
CoordinationContext header element with the context identifier and the address of the
registration service.
Steps for example (2)
9. MyShippingService sends a Register message to the registration
service to enter into the existing coordination context, requesting to
use the completion with acknowledgment protocol.
10. The registration service returns a RegisterResponse message.
11. With all of the services enrolled in the transaction, the coordinator
sends a Prepare message to MyOrderService and
MyInventoryService to begin the two-phase commit process. Since
MyShippingService isn't using two-phase commit, it doesn't receive
the Prepare message
Steps for example (3)
12. After recording the transaction in a recoverable way,
MyOrderService and MyInventoryService return a Prepared
message to the coordinator.
13. After receiving the Prepared message, the coordinator sends a
Commit message to all three services.
14. After successfully committing the changes, MyOrderService and
MyInventoryService return a Committed message to the
coordinator, and MyShippingService returns a Notified message.
Key Points
• WS-AtomicTransaction is a coordination
type that supplies five coordination
protocols that can be used to achieve twophase commit transactions across multiple
service participants.
• The atomic transaction coordinator makes
the ultimate decision to commit or rollback
a transaction. This decision is based on
votes collected from participants.
Final Considerations
1.
Il punto fondamentale di questo protocollo è quindi il
blocco delle risorse finché non si è sicuri che tutto sia
stato eseguito correttamente. Questa pratica non è
adatta in ambiente Web.
1.
2.
In primo luogo il Web è caratterizzato da comunicazioni
asincrone e non affidabili ; questo ostacola l’implementazione
di un protocollo 2PC in quanto il coordinatore non può essere
certo del tempo impiegato da un partecipante a rispondere ai
suoi messaggi di prepare e di commit e rischia di attendere
indefinitamente.
Anche l’uso di timeout per ovviare a questo problema non offre
una valida soluzione perché timeout troppo corti possono
causare l’abort di un numero eccessivo di transazioni che
invece sarebbero andate a buon fine, mentre timeout troppo
lunghi possono tenere molte risorse bloccate inutilmente per
tempi inaccettabili.
Final Considerations
2.
Secondariamente bisogna considerare che
un’organizzazione che partecipi ad una transazione
difficilmente sarebbe disposta a bloccare le proprie
risorse per lungo tempo.
1.
È principalmente per questi motivi che si è ormai diffusa l’idea
di rilassare i vincoli imposti dalle proprietà ACID quando si ha
a che fare con BT a lungo termine che spaziano tra i domini di
più organizzazioni diverse.
2.
Data la loro natura, le BT a breve termine possono essere
implementate secondo i classici protocolli 2PC. Tipicamente
infatti le operazioni di una BT a breve termine sono
completamente automatizzate (e quindi eseguite in tempi
brevissimi) e non escono dai confini di un’organizzazione.
BT a lungo termine
• Viene considerata come un insieme di
transazioni a breve termine.
• Il coordinatore fa in modo che ognuna di queste
venga eseguita indipendentemente dalle altre e
raccoglie i vari esiti che gli giungeranno in
diversi istanti di tempo. Generalmente alcuni
saranno dei commit e altri degli abort.
• A seconda di quali transazioni sono andate a
buon fine e quali no, verrà presa una decisione
(da una specifica applicazione di business o
direttamente dal cliente) sull’esito globale della
BT.
Not offer rollback capabilities
COMPENSATION PROCESS
Business activity protocols
• The
BusinessAgreementWithParticipantCompletion
protocol, which allows a participant to
determine when it has completed its part in the
business activity.
• The
BusinessAgreementWithCoordinatorCompletion
protocol, which requires that a participant rely
on coordinator to notify it that it has no further
processing responsibilities.
Business activity coordinator
Abort di una BT e compensazione
• Quando una transazione atomica fallisce viene garantito un rollback automatico, ma per una BT occorre attivare transazioni di
compensazione che svolgano le operazioni inverse di quelle fatte da
tutte le transazioni che inizialmente avevano eseguito il commit.
• Questo approccio, noto come backward recovery, non è sempre
possibile poiché può capitare che alcune operazioni siano
irreversibili.
– In questo caso si deve procede secondo un altro approccio (forward
recovery) che dà il via a nuove transazioni le quali, preso atto dei
cambiamenti ormai avvenuti, riconducono il processo ad uno stato
“simile” a quello di partenza.
– Una situazione di questo tipo può verificarsi, ad esempio, quando viene
annullato un ordine per l’acquisto di merci che sono già state spedite.
Infatti, anche se le merci vengono rimandate indietro, bisogna
comunque far fronte alle spese di spedizione e di conseguenza lo stato
finale non potrà mai essere uguale a quello di partenza..
Business activity states (1/2)
• Active State
• Completed state
– a participant can indicate that it has completed the processing it
was required to perform as part of the activity by issuing a
completed notification.
– This moves the participant from an active state to a completed
state.
– The coordinator may respond with a close message to let the
participant know that the business activity is being successfully
completed.
• Compensation state
– Participants can enter a compensation state during which they
attempt to perform some measure of exception handling. This
generally invokes a separate compensation process that could
involve a series of additional processing steps.
Business activity states (2/2)
• Cancelled state
– Alternatively to compensation state;
– This typically results in the termination of any further processing
outside of the cancellation notifications that need to be
distributed
• Exit state
– What also distinguishes business activities from atomic
transactions is the fact that participating services are not
required to remain participants for the duration of the activity.
– Because there is no tight control over the changes performed by
services, they may leave the business activity after their
individual contributions have been performed.
– When doing so, participants enter an exit state by issuing an exit
notification message to the business activity coordinator.
Business activity and atomic
transactions
Key Points
• Business activities manage complex, long-running activities
that can vary in scope and in the amount of participating
services.
• WS-BusinessActivity builds on the WS-Coordination context
management framework by providing two protocols for
which activity participants can register.
• Participants and the business activity coordinator progress
through a series of states during the lifespan of a business
activity. State transition is accomplished through the
exchange of notification messages.
Web Service Transaction Summary
• WS-Atomic Transaction and WSBusinessActivity “leverage” WS-Coordination
definendo due tipi di coordinamento :
– Short term atomic transaction
– Long duration business activity
ORCHESTRATION
• With orchestration, different processes can be
connected without having to redevelop the
solutions that originally automated the
processes individually.
• Orchestration bridges this gap by introducing
new workflow logic.
• Further, the use of orchestration can significantly
reduce the complexity of solution environments.
• Workflow logic is abstracted and more easily
maintained than when embedded within
individual solution components.
Orchestration Control
Language specification
• A primary industry specification that
standardizes orchestration is the Web
Services Business Process Execution
Language (WS-BPEL).
• WS-BPEL is the most recent name given
to this specification, which also is known
as BPEL4WS and just BPEL.
Business protocols and process
definition
• The workflow logic that comprises an
orchestration can consist of numerous business
rules, conditions, and events.
• a business protocol defines how participants
can interoperate to achieve the completion of a
business task.
• The details of the workflow logic encapsulated
and expressed by an orchestration are
contained within a process definition.
Process services and partner
services
• First, the process
itself is represented
as a service, resulting
in a process service
• Other services
allowed to interact
with the process
service are identified
as partner services or
partner links
Basic activities and structured
activities
• WS-BPEL breaks down workflow logic into
a series of predefined primitive activities.
• Basic activities (receive, invoke, reply,
throw, wait) represent fundamental
workflow actions which can be assembled
using the logic supplied by structured
activities (sequence, switch, while, flow,
pick).
Some activities
• Sequence
– aligns groups of related activities into a list that
determines a sequential execution order.
• Flows
– also contain groups of related activities, but they
introduce different execution requirements.
• Links
– are used to establish formal dependencies between
activities that are part of flows. Before an activity fully
can complete, it must ensure that any requirements
established in outgoing links first are met.
Orchestration and coordination
Orchestration, as represented by WS-BPEL, can
fully utilize the WS-Coordination context
management framework by incorporating the
WS-BusinessActivity coordination type.
Key Points
• An orchestration expresses a body of business process
logic that is typically owned by a single organization.
• An orchestration establishes a business protocol that
formally defines a business process definition.
• The workflow logic within an orchestration is broken
down into a series of basic and structured activities that
can be organized into sequences and flows.
• Orchestration has been called the "heart of SOA," as it
establishes a means of centralizing and controlling a
great deal of inter and intra-application logic through a
standardized service model.
Choreography
• A choreography is essentially a collaboration
process designed to allow organizations to
interact in an environment that is not owned by
any one partner.
• The Web Services Choreography Description
Language (WS-CDL) is one of several
specifications that attempts to organize
information exchange between multiple
organizations (or even multiple applications
within organizations), with an emphasis on
public collaboration
A choreography enables collaboration
between its participants.
Choreography elements
• Roles
– This establishes what the service does
• Relationship
– Each potential exchange between two roles
• Channels
– defining the characteristics of the message
exchange between two specific roles
Interactions and work units
• Interactions are the fundamental building
blocks of choreographies.
– the completion of an interaction represents
actual progress within a choreography.
• Related to interactions are work units.
– These impose rules and constraints that must
be adhered to for an interaction to
successfully complete
Orchestrations and choreographies
• While both represent complex message interchange
patterns, there is a common distinction that separates
the terms "orchestration" and "choreography."
• An orchestration expresses organization-specific
business workflow.
– This means that an organization owns and controls the logic
behind an orchestration, even if that logic involves interaction
with external business partners.
• The choreography acts as a community interchange
pattern used for collaborative purposes by services from
different provider entities
– A choreography, on the other hand, is not necessarily owned by
a single entity.
A choreography enabling collaboration
between two different orchestrations
Orchestrations and choreographies
• One can view an orchestration as a business-specific
application of a choreography.
– This view is somewhat accurate, only it is muddled by the fact
that some of the functionality provided by the corresponding
specifications (WS-CDL and WS-BPEL) actually overlaps.
– This is a consequence of these specifications being developed in
isolation and submitted to separate standards organizations
(W3C and OASIS, respectively).
• An orchestration is based on a model where the
composition logic is executed and controlled in a
centralized manner.
• A choreography typically assumes that there is no single
owner of collaboration logic.
Web Services
Orchestration
• Execution order of web
services interactions
• Describes process flow
• Includes internal and external
webservices
• Process is always controlled by
one party
Web Services
Choreography
• Tracks the sequence of
messages involving multiple
parties and sources
• Public message exchanges, not
executable processes
• Collaborative - no single
“controller”
web
service
web
service
Collaboration
web
service
Process flow
web
service
web
service
web
service
Example of Web Services
Composition
Orchestration-Centric Approach
receive 'OpenAccountRequest'
invoke CollectAccountInfo
invoke ValidateAccountInfo
assign AccountInfoInvalid =
ValidateAccountInfoResponse
while AccountInfoInvalid = true
invoke RepairAccountInfo
pick onRepairAccountInfoCB
invoke
ValidateAccountInfo
assign
AccountInfoInvalid =
ValidateAccountInfoResponse
otherwise // timeout assume AccountInfo can't be repaired
invoke
DeclineAccountApplication
terminate
end pick
end while
invoke OpenAccount
invoke SendConfirmation
Choreography-Centric Approach
•CollectAccountInformation and
ValidateAccountInformation
•ValidateAccountInformation and
RepairAccountInformation.
•ValidateAccountInformation and
OpenAccount.
•OpenAccount and
SendConfirmation.
•RepairAccountInformation and
DeclineAccountApplication
KEY POINTS
• A choreography is a complex activity
comprised of a service composition and a
series of MEPs.
• Choreographies consist of multiple
participants that can assume different
roles and that have different relationships.
• Choreographies are reusable,
composable, and can be modularized.
LIFE CYCLE di una transazione che può
partecipare come sottotransazione in 2PC
done
initialized
computing
precommitted
Internal
error
Ciascuna TR appena partita
entra in uno stato in cui esegue
la sua local computation
aborted
failure
committed
forgotten
ESEMPIO di ESECUZIONE di una “PC
SubTR1
Coordinator
SubTR2
register
register
vote
vote
decision
decision
Quando il
coordinatore
parte registra le
sottotransazioni
Se si ha
l’unanimità di
commit allora il
coordinatore
annuncia una
commit decisione
altrimenti un abort
decision (
rollback)
• Ogni partecipante può aggiornare il suo
stato dopo ciascun passo della
transazione
• I risultati di un task sono visibili prima della
fine della transazione
• I vincoli di atomicità ed Isolamento sono
“relaxed”
• L’operazione di compensazione in caso di
fallimento fa perdere semanticamente gli
effetti dell’esecuzione parziale della
transazione
• Ciascuna operazione può avere una
differente logica di compensazione
• Ciascun provider può avere una differente
opinione riguardo l’esatto significato di
compensare una operazione
– Disdetta reservation con pagamento penale o
no
Short term atomic transaction
(example)
• Travel agency deve trovare un volo per un
cliente che deve visitare un museo
• Travel Agency e Airline hanno i propri
coordinatori (registration ed activation
service)
Museum Server
Travel Agency
Server
Airline Server
WS
WS
(1) commit
WS
(4) prepare (5)
(3)prepare
prepared
(2)prepare
COORD.
(6)prepared
COORD.
(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 protocol
3. I servizi coinvolti si dichiarano pronti ad eccezione del museo che risponde
con un messaggio ed abbandona la transazione
Travel Agency Server
Airline Server
WS
WS
(9) vote
(10) voted
(12) voted
(8) vote
COORD.
(11) voted
Notifica del voto e votazione
COORD.
Business Activity example
• Tre web services (A B C) con un
coordinatore R
• A inizia il protocollo mentre B e C vi
partecipano
Web service A
Web service B
Web service C
Coordinator R
create CC
A1
operational message
operational message
register for BusinessAgreement
BusinessAgreement coordinator
register for BusinessAgreement
BusinessAgreement
coordinator
completed
faulted
compensate
forget
A inizia la Business Activity e passa il contesto a B e C che si registrano con
B finisce
il suo
lavoro
mentre
C incontra un errore
riceve
il fault
message
RSe
perquando
il BusinessAgreement
ProtocolR ha già ricevuto il messaggio completed
da B manda a B un messaggiio “compensate” altrimenti “cancelled”
Infine R manda un forget message to C
HelloService.wsdl