WS-* and contemporary SOA

1
PART IV - WS- and contemporary SOA Activity
Management and Composition
1. Message Exchange Patterns
2
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 UDDI.
• 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.)

3
Specifications and Concepts
4
1. Message Exchange Patterns
5
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 task.
• 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

6
MEP (II)

• 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 requirement.
• 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
  solutions.

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

8
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.
9
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.
10
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

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

12
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
13
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-and-subscribe
  model

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

15
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.
16
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 definition.
• 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.

17
WSDL support Request-response operation

• Upon receiving a message, the service must
  respond with a standard message or a fault
  message.

18
WSDL support Solicit-response operation

• Upon submitting a message to a service requestor,
  the service expects a standard response message
  or a fault message.

19
WSDL support One-way operation

• The service expects a single message and is not
  obligated to respond.

20
WSDL support Notification operation

• The service sends a message and expects no
  response.

21
MEPs and SOAP

• SOAP standard provides a messaging framework
  designed to support single-direction message
  transfer.
• 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.

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

23
2. Service ACTIVITY
24
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

25
Simple or primitive activity

• A simple or primitive activity is typified by
  synchronous communication and therefore often
  consists of two services exchanging information
  using a standard request-response MEP

26
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

27
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

28
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 environmental conditions. The message
subsequently arrives at TLS's Accounts Payable
Service.
3. The Accounts Payable Service acts as a
controller and initiates a service composition to
begin processing the message contents. It begins
by interacting with the Vendor Profile Service to
validate invoice header data and attaches the
invoice document to the vendor account.
4. The Accounts Payable Service then extracts
taxes, shipping fees, and the invoice total. It
passes these values to the Ledger Service, which
updates various ledger accounts, including the
General Ledger
5. Finally the activity ends, as the Accounts
Payable Service completes its processing cycle
by sending a response message back to RailCo
29
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

30
3. COORDINATION
31
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

32
Coordination framework

• provide a means for context information in
  complex activities to be managed, preserved
  and/or updated, and distributed to activity
  participants.

33
Example
34
Car wash simple task
35
Car wash steps
Locate bucket. - Locate sponge. Locate hose
36
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 context information.

37
Coordinator service model
WS-Coordination establishes a framework that
introduces a generic service based on the
coordinator service model
38
Services of Coordinator Composition

• 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

39
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 is extensible and
  can be utilized by different coordination types.
• WS-AtomicTransaction
• WS-BusinessActivity
• Coordination type extensions provide a set of
  coordination protocols

40
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

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

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

43
The instantiated process
This invitation consists of the context
information the application service originally
received from the activation service.
Upon a successful registration, a service is
officially a participant. The registration
service passes the service the location of the
coordinator service, with which all participants
are required to interact.
Any Web service in possession of this context
information may issue a registration request to
the registration service. This allows the service
to enlist in a coordination based on a specific
protocol.
Via a CreateCoordinationContext request message,
it asks the activation service to generate a set
of new context data. Once passed back with the
ReturnContext message, the application service
now can invite other services to participate in
the coordination.
The coordination service composition is
instantiated when an application service contacts
the activation service
44
The completion process
The application service can request that a
coordination be completed by issuing a completion
request message to the coordination service.
The coordinator, in turn, then issues its own
completion request messages to all coordination
participants. Each participant service responds
with a completion acknowledgement message
45
Coordination and SOA
46
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
invoice header data. If the data is valid, the
invoice document is attached to the vendor
account.4. The Accounts Payable Service
extracts taxes and shipping fees from the invoice
document. These values, along with the invoice
total, are submitted to the Ledger Service. The
Ledger Service is responsible for updating the
General Ledger and numerous sub-ledgers, such as
the Accounts Payable Ledger.
In the previous case study example, we
established the individual process steps that
comprised a complex activity. Once the processing
of this activity enters the TLS environment, TLS
employs a context management system to coordinate
the flow of the message through its internal
services.
47
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

48
4. BUSINESS TRANSACTION (BT)
49
PRODROMI

• Lautomazione 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 specifiche regole.
• fornire gli strumenti per definire la logica di
  business, il formato e la sequenza di messaggi
  necessari per conseguire il risultato voluto.
• La sincronizzazione delle attività che vengono
  svolte allinterno 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
  ununica componente logica di lavoro che presenti
  un solo risultato visibile allesterno (commit o
  abort)

50
DEFINITION

• 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
  essi.
• In generale le proprietà delle transazioni sono
  conosciute come proprietà ACID, ossia che
  assicurano Atomicità, Consistenza, Isolamento e
  Persistenza (Durabilità).

51
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 lesito della
  transazione deve dipendere da decisioni umane) e
  unorganizzazione 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 lorchestrazione.

52
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
  lordine 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.

53
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, sia a
  breve termine che a lungo termine, 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.
• 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.

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

55
ATOMIC TRANSACTION

• Atomic transactions implement the familiar
  commit and rollback features to enable
  cross-service transaction support ( traditional
  two- phase transaction protocol )

56
Washing process example

• This change to our process affects the following
  two steps
• Fill bucket with warm water.
• 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.

57
Atomic Transaction Protocols

• Completion
• which is typically used to initiate the commit or
  abort states of the transaction.
• Two-Phase Commit (2PC)

58
Two-Phase Commit

• 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 transaction.
• 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..

59
Maintain to ACID properties of data

• Atomic
• Latomicità rappresenta il fatto che la
  transazione è ununita indivisibile di
  esecuzione o vengono resi visibili tutti gli
  effetti di una transazione, oppure la transazione
  non deve avere alcun effetto. Viene quindi
  seguito un approccio tutto o niente dove non è
  possibile lasciare la transazione in uno degli
  stati intermedi attraversati durante
  lelaborazione
• 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 lesecuzione di una transazione sia
  completamente indipendente dalla contemporanea
  esecuzione di altre transazioni. In un ambiente
  distribuito lisolamento nasconde anche gli stati
  intermedi di una transazioni rendendoli
  inaccessibili dallesterno..
• Durable
• richiede che leffetto di una transazione che
  abbia eseguito il commit correttamente non venga
  più perso.

60
The atomic transaction coordinator

• This particular implementation of the
  WS-Coordination coordinator service represents a
  specific service model.
• The atomic transaction coordinator plays a key
  role in managing the participants of the
  transaction process and in deciding the
  transaction's ultimate outcome

61
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

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

63
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

64
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

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

66
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 CreateCoordinationContextR
   esponse 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.

67
Steps for example (1)

1. 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.
2. MyInventoryService sends a Register message to
   the registration service to enter into the
   existing coordination context, also using the
   two-phase commit protocol.
3. The registration service returns a
   RegisterResponse message.
4. 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.

68
Steps for example (2)

1. MyShippingService sends a Register message to the
   registration service to enter into the existing
   coordination context, requesting to use the
   completion with acknowledgment protocol.
2. The registration service returns a
   RegisterResponse message.
3. 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

69
Steps for example (3)

1. After recording the transaction in a recoverable
   way, MyOrderService and MyInventoryService return
   a Prepared message to the coordinator.
2. After receiving the Prepared message, the
   coordinator sends a Commit message to all three
   services.
3. After successfully committing the changes,
   MyOrderService and MyInventoryService return a
   Committed message to the coordinator, and
   MyShippingService returns a Notified message.

70
Atomic Transaction and SOA
71
Key Points

• 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
  WS-AtomicTransaction.

72
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.
2. In primo luogo il Web è caratterizzato da
   comunicazioni asincrone e non affidabili questo
   ostacola limplementazione di un protocollo 2PC
   in quanto il coordinatore non può essere certo
   del tempo impiegato da un partecipante a
   rispondere ai suoi messaggi di prepare e di
   commit e rischia di attendere indefinitamente.
3. Anche luso di timeout per ovviare a questo
   problema non offre una valida soluzione perché
   timeout troppo corti possono causare labort di
   un numero eccessivo di transazioni che invece
   sarebbero andate a buon fine, mentre timeout
   troppo lunghi possono tenere molte risorse
   bloccate inutilmente per tempi inaccettabili.
4. Secondariamente bisogna considerare che
   unorganizzazione che partecipi ad una
   transazione difficilmente sarebbe disposta a
   bloccare le proprie risorse per lungo tempo.
5. È principalmente per questi motivi che si è ormai
   diffusa lidea di rilassare i vincoli imposti
   dalle proprietà ACID quando si ha a che fare con
   BT a lungo termine che spaziano tra i domini di
   più organizzazioni diverse.
6. Data la loro natura, le BT a breve termine
   possono essere implementate secondo i classici
   protocolli 2PC. Tipicamente infatti le operazioni
   di una BT a breve termine sono completamente
   automatizzate (e quindi eseguite in tempi
   brevissimi) e non escono dai confini di
   unorganizzazione.

73
BT a lungo termine

• Viene considerata come un insieme di transazioni
  a breve termine.
• Il coordinatore fa in modo che ognuna di queste
  venga eseguita indipendentemente dalle altre e
  raccoglie i vari esiti che gli giungeranno in
  diversi istanti di tempo. Generalmente alcuni
  saranno dei commit e altri degli abort.
• A seconda di quali transazioni sono andate a buon
  fine e quali no, verrà presa una decisione (da
  una specifica applicazione di business o
  direttamente dal cliente) sullesito globale
  della BT.

74
Business activities

• 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
  protocols.
• 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

75
Not offer rollback capabilities
COMPENSATION PROCESS
76
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 the business activity coordinator to notify it
  that it has no further processing
  responsibilities.

77
Business activity coordinator
78
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
  lacquisto di merci che sono già state spedite.
  Infatti, anche se le merci vengono rimandate
  indietro, bisogna comunque far fronte alle spese
  di spedizione e di conseguenza lo stato finale
  non potrà mai essere uguale a quello di partenza..

79
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
  specification.
• These tables establish the fundamental rules of
  the business activity protocols by determining
  the sequence and conditions of allowable states.

80
State example

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

81
State example

• Cancelled 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.

82
Business activity and atomic transactions
83
Business activity and SOA
84
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.
• 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 activities

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

86
Orchestration Control
87
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.

88
Business protocols and process definition

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

89
Process services and partner services

• Identified and described within a process
  definition are the allowable process
  participants.
• 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

90
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).

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

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

93
Orchestration and SOA
94
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.

95
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

96
A choreography enables collaboration between its
participants.
97
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

98
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
  choreography.
• Related to interactions are work units.
• These impose rules and constraints that must be
  adhered to for an interaction to successfully
  complete

99
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.
• 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 provider entities

100
A choreography enabling collaboration between two
different orchestrations
101
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.
• 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.

102

• 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

webservice
webservice
Collaboration
webservice
webservice
Process flow
webservice
webservice
103
Choreography and SOA
104
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.
• The concept of choreography extends the SOA
  vision to standardize cross-organization
  collaboration.