PART IV - WS-* and contemporary SOA
Activity Management and Composition
1. Message Exchange
What is "WS-*"?
• The term "WS-*" has become a commonly used
abbreviation that refers to the second-generation
Web services specifications.
• These are extensions to the basic Web services
framework established by first-generation
standards represented by WSDL, SOAP, and
• The term "WS-*" became popular because the
majority of titles given to second-generation Web
services specifications have been prefixed with
"WS-". (See www.specifications.ws for examples
of WS-* specifications.)
Specifications and Concepts
1. Message Exchange
Message Exchange Patterns (1)
• Every task automated by a Web service can
differ in both the nature of the application logic
being executed and the role played by the
service in the overall execution of the business
• 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
• Message exchange patterns (MEPs)
represent a set of templates that provide a
group of mapped out sequences for the
exchange of messages.
• Many MEPs have been developed, each
addressing a common message exchange
– It is useful to have a basic understanding of some of
the more important MEPs,
– applying MEPs to specific communication
requirements when designing service-oriented
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
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
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
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
• 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-and-
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
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
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
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.
• The association of MEPs to WSDL operations thereby
insert expected conversational into the interface
• WSDL operations support different configurations of
incoming, outgoing, and fault messages. These
configurations are equivalent to message exchange
patterns, but within the WSDL specification, they often
are referred to simply as patterns.
WSDL support : Request-response
• Upon receiving a message, the service
must respond with a standard message or
a fault message.
WSDL support : Solicit-response
• 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
• The service sends a message and expects
MEPs and SOAP
• SOAP standard provides a messaging
framework designed to support single-direction
• The extensible nature of SOAP allows countless
messaging characteristics and behaviors (MEP-
related and otherwise) to be implemented via
SOAP header blocks.
• The SOAP language also provides an optional
parameter that can be set to identify the MEP
associated with a message.
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 and SOAP specifications support specific
variations of common MEPs.
2. Service ACTIVITY
– In service-oriented solutions, each task can
involve any number of services.
• The interaction of a group of services
working together to complete a task can
be referred to as a service activity
Simple or primitive activity
• A simple or primitive activity is typified by
synchronous communication and therefore
often consists of two services exchanging
information using a standard request-
• 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
• 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
3. The Accounts conditions. The acts as a controller and initiates TLS's Accounts Payable Service
to environmental Payable Servicemessage subsequently arrives ata service composition to begin
processing the message contents. It begins by interacting with the Vendor Profile Service to
4. The Accounts Payable Service then extracts taxes, shipping fees, vendor invoice total.
validate invoice header data and attaches the invoice document to the and the account.
It passes these values to the Ledger Service, which updates various ledger accounts,
including the General Ledger as the Accounts Payable Service completes
5. Finally the activity ends,
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
• Every activity introduces a level of context into an application
• 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
• 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,
– 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
• provide a means
to be managed,
Car wash simple task
Wash the car
Car wash steps
Locate bucket. - Locate sponge.
I Locate hose
Car wash considerations
• In this scenario, the bucket availability status is considered context
information that I managed.
• Because a separate context manager was in place, Chuck was alleviated
of the responsibility of remembering and communicating the context
information to Bob.
• This liberate Chuck to continue with his other work.
• It also spared 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
Coordinator service model
based on the
This service controls a composition of three other services that each
play a specific part in the management of context data.
Services of Coordinator
• Activation service
– Responsible for the creation of a new context and for
associating this context to a particular activity.
• Registration service
– Allows participating services to use context
information received from the activation service to
register for a supported context protocol.
• Protocol-specific services
– These services represent the protocols supported by
the coordinator's coordination type.
• Coordination service.
– The controller service of this composition
• Each coordinator is based on a coordination
type, which specifies the nature and underlying
logic of an activity for which context information
is being managed.
• The WS-Coordination framework is extensible
and can be utilized by different coordination
• Coordination type extensions provide a set of
• The actual process that a coordinator uses to
communicate with an application is defined by
the coordination protocol chosen by the
• The coordination protocol defines a series of
messages between the coordinator and each
application that is participating in the
• In a single coordination, each participating Web
service application can request to use a different
protocol when communicating with the
• A context created by the activation service is referred to as a
• 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
• 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.
• 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.
consists of the
Any is officiallythe
service Web service
a participant. Theof
theissue a the
location of the
service composition is
instantiated asks an
message, it the
which all theset of new
contacts a activation
service data. Once
context the service
required to in a
passed back with the
based on a
now can invite other
services to participate
in the coordination.
The application service
can request that a
completed by issuing a
message to the
The coordinator, in turn,
then issues its own
messages to all coordination
participant service responds
with a completion
Coordination and SOA
Case Study 4.3.1
As shown in Figure coordination is applied to the following steps:
3. The Accounts Payable Service uses the Vendor Profile Service to validate the
In the previous case study example, the invoice document is attached to the
invoice header data. If the data is valid, we established the individual
vendor account. that comprised a complex activity. Once the processing
of this activity enters the TLS environment, TLS employs a context
management Payable Service extracts taxes the message through the
4. The Accounts system to coordinate the flow ofand shipping fees fromits
invoice document. These values, along with the invoice total, are submitted to
the Ledger Service. The Ledger Service is responsible for updating the General
Ledger and numerous sub-ledgers, such as the Accounts Payable Ledger.
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)
• L’automazione di processi di business complessi non
può essere realizzata adeguatamente con gli attuali
sistemi di scambi di messaggi ma necessita di un
apposito framework che assicuri che le transazioni che
costituiscono il processo siano condotte secondo
– fornire gli strumenti per definire la logica di business, il formato e
la sequenza di messaggi necessari per conseguire il risultato
• La sincronizzazione delle attività che vengono svolte
all’interno dei singoli partecipanti al processo deve
essere gestita tenendo conto della natura dello scenario
dove avviene la comunicazione (ad esempio il Web);
• Queste attività spesso devono essere viste come
un’unica componente logica di lavoro che presenti un
solo risultato visibile all’esterno (commit o abort)
• Con il termine Business Transaction si indica un
cambiamento consistente nello stato di un processo
condotto tra diverse organizzazioni.
• Il concetto di transazione è molto diffuso nella gestione
di grandi collezioni di dati:
– 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
• In generale le proprietà delle transazioni sono
conosciute come proprietà ACID, ossia che assicurano
Atomicità, Consistenza, Isolamento e Persistenza
Business Transaction Framework
• Una BT richiede le stesse proprietà ma, poiché esiste in
un ambiente profondamente diverso da quello di un
Database, deve affrontare problematiche di altro tipo.
• Comunemente le transazioni vengono realizzate tramite
protocolli di tipo Two Phase Commit (2PC)
• Inoltre una BT può avere una durata molto lunga (anche
di ore o giorni se l’esito della transazione deve dipendere
da decisioni umane) e un’organizzazione difficilmente
accetterebbe di vedere le proprie risorse bloccate per
tutto questo tempo,
• Un Business Transaction Framework (BTF) deve quindi
essere costruito al di sopra di una piattaforma per
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
• 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. Protocolli di questo tipo possono anche servire ai partner
per scambiarsi informazioni prima di effettuare la transazione e per
prendere accordi sulle modalità di esecuzione.
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
• Le BT a lungo termine (o semplicemente BT) possono essere viste come un
insieme di BT, sia a breve termine che a lungo termine, legate da una logica
– 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.
– Anche le BT a lungo termine possono essere quindi annidate a piacimento;
questo garantisce una grande flessibilità e può aiutare a definire transazioni
complesse più robuste e più facili da gestire in caso di errori ed eccezioni.
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
• Atomic transactions implement the familiar
commit and rollback features to enable cross-
service transaction support ( traditional two-
phase transaction protocol )
Washing process example
• This change to our process affects the following two
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.
Atomic Transaction Protocols
– which is typically used to initiate the
commit or abort states of the transaction.
• Two-Phase Commit (2PC)
• Two-phase commit is the main protocol used for
completing transactions while maintaining the ACID
properties of data since by requesting that data be
written to disk it ensures that all participants in the
transaction will be able to commit their part of the
transaction, even if a hardware failure occurs during the
• 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
Maintain to ACID properties of data
– 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
– richiede che al termine della transazione tutti i dati manipolati siano coerenti con
la semantica della transazione stabilita da una logica di business.
– 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
– richiede che l’effetto di una transazione che abbia eseguito il commit
correttamente non venga più perso.
The atomic transaction coordinator
• This particular
implementation of the
represents a specific
• The atomic
coordinator plays a
key role in managing
the participants of the
and in deciding the
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
• 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.
• Each participant's vote consists of either a "commit" or "abort"
• In base al risultato ottenuto comunicano al coordinatore la loro
capacità di eseguire correttamente il commit o meno
• Now reviews all votes and decides whether to commit or rollback the
• 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
– 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
Examples of a Coordinated
• A single coordinator service manages an atomic transaction among three
• 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.
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
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.
Atomic Transaction and SOA
• WS-AtomicTransaction is a coordination type
that supplies three coordination protocols that
can be used to achieve two-phase commit
transactions across multiple service participants.
• The atomic transaction coordinator makes the
ultimate decision to commit or rollback a
transaction. This decision is based on votes
collected from participants.
• Contemporary SOAs can incorporate cross-
service, ACID-type transaction features by using
1. Il punto fondamentale di questo protocollo è quindi il blocco delle risorse
finché non si è sicuri che tutto sia stato eseguito correttamente. Questa
pratica non è adatta in ambiente Web.
1. In primo luogo il Web è caratterizzato da comunicazioni asincrone e non
affidabili ; questo ostacola 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
2. 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
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
• Business activities govern long-running,
complex service activities.
• What distinguishes a business activity from a
regular complex activity is that its participants
are required to follow specific rules defined by
• Business activities primarily differ from the also
protocol-based atomic transactions in how they
deal with exceptions and in the nature of the
constraints introduced by the protocol rules
Not offer rollback capabilities
Business activity protocols
protocol, which allows a participant to determine
when it has completed its part in the business
protocol, which requires that a participant rely on
the business activity coordinator to notify it that it
has no further processing responsibilities.
Business activity coordinator
Abort di una BT e compensazione
• Quando una transazione atomica fallisce viene garantito
un roll-back automatico, ma per una BT occorre iniziare
delle transazioni di compensazione che svolgano le
operazioni inverse di quelle fatte da tutte le transazioni
che inizialmente avevano eseguito il commit.
• Questo approccio, noto come backward recovery, non è
sempre possibile poiché può capitare che alcune
operazioni siano irreversibili.
• In questo caso si deve procede secondo un altro
approccio (forward recovery) che dà il via a nuove
transazioni le quali, preso atto dei cambiamenti ormai
avvenuti, riconducono il processo ad uno stato “simile” a
quello di partenza.
– Una situazione di questo tipo può verificarsi, ad esempio,
quando viene annullato un ordine per 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
• During the lifecycle of a business activity, the
business activity coordinator and the activity
participants transition through a series of states.
• The actual point of transition occurs when
special notification messages are passed
between these services
• states are defined in a series of state tables
documented as part of the WS-BusinessActivity
• These tables establish the fundamental rules of
the business activity protocols by determining
the sequence and conditions of allowable states.
• Completed state
– For example, a participant can indicate that it has completed the
processing it was required to perform as part of the activity by
issuing a completed notification. This moves the participant from
an active state to a completed state. The coordinator may
respond with a close message to let the participant know that the
business activity is being successfully completed.
• Compensation state
– However, if things don't go as planned during the course of a
business activity, one of a number of options are available.
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.
• Cancelled state
– This typically results in the termination of any further processing
outside of the cancellation notifications that need to be
• 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
Business activity and SOA
• 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
• 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.
• Long-running activities are commonplace in contemporary SOAs, which
positions WS-BusinessActivity as an important specification for the
controlled management of logic that underlies these types of complex
• With orchestration, different processes can be
connected without having to redevelop the
solutions that originally automated the
• 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.
• A primary industry specification that
standardizes orchestration is the Web
services Business Process Execution
• WS-BPEL is the most recent name given
to this specification, which also is known
as BPEL4WS and just BPEL.
Business protocols and process
• The workflow logic that comprises an
orchestration can consist of numerous business
rules, conditions, and events.
• Collectively, these parts of an orchestration
establish a business protocol that defines how
participants can interoperate to achieve the
completion of a business task.
• The details of the workflow logic encapsulated
and expressed by an orchestration are
contained within a process definition.
Process services and partner
• Identified and described
within a process
definition are the
• First, the process itself is
represented as a service,
resulting in a process
• Other services allowed to
interact with the process
service are identified as
partner services or
Basic activities and structured
• 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,
– aligns groups of related activities into a list that
determines a sequential execution order.
– also contain groups of related activities, but they
introduce different execution requirements.
– 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.
Orchestration and SOA
• 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.
• 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
A choreography enables collaboration
between its participants.
– This establishes what the service does
– Each potential exchange between two roles
– defining the characteristics of the message
exchange between two specific roles
Interactions and work units
• the actual logic behind a message exchange is
encapsulated within an interaction.
• Interactions are the fundamental building blocks
of choreographies because the completion of an
interaction represents actual progress within a
• 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
– This means that an organization owns and controls the logic
behind an orchestration, even if that logic involves interaction
with external business partners.
• A choreography, on the other hand, is not necessarily
owned by a single entity.
• It acts as a community interchange pattern used for
collaborative purposes by services from different
A choreography enabling collaboration
between two different orchestrations
Orchestrations and choreographies
• One can view an orchestration as a business-specific application of
– 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
• 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
– However, one area of overlap between the current orchestration and
choreography extensions is the fact that orchestrations can be designed
to include multi-organization participants. An orchestration can therefore
effectively establish cross-enterprise activities in a similar manner as a
choreography. Again, though, a primary distinction is the fact that an
orchestration is generally owned and operated by a single organization.
Web Services Web Services
• Execution order of web • Tracks the sequence of
services interactions messages involving multiple
• Describes process flow parties and sources
• Includes internal and external • Public message exchanges, not
webservices executable processes
• Process is always controlled by • Collaborative - no single
one party “controller”
web Process flow web
Choreography and SOA
• 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
• Choreographies are reusable, composable, and
can be modularized.
• The concept of choreography extends the SOA
vision to standardize cross-organization