WS-

Document Sample
WS- Powered By Docstoc
					PART IV - WS-* and contemporary SOA
 Activity Management and Composition




     1. Message Exchange
           Patterns
            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.)
Specifications and Concepts
1. Message Exchange
      Patterns
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
                     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.
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-and-
  subscribe 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.
• 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.
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.
           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.
              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
            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-
  response 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
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
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




                     Prepare Water
 bob



                    Wash the car

jim
              Car wash steps
                          Locate bucket. - Locate sponge.
I                         Locate hose
      chuck


               II
II
                                          chuck
                    bob
       bob



III                  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 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.
      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.
        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
            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
        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
     This invitation
     consists of the
  instantiated
     context information
Upon a
     the application
successful
    process
     service originally
registration, a
     received from
    Any is officiallythe
service Web service
     activation service.
a participant. Theof
    in possession
registration
    this context
service passesmay
    information
  Via a
      service
theissue a the
 The coordination
  CreateCoordinationCo
location of the
 service composition is
    registration
  ntext request
coordinatortowhen the
 instantiated asks an
    request
  message, it the
service, withserviceto
 applicationservice
    registration
  activation
which all theset of new
 contacts a activation
    service.
  generate This
participants are
 service data. Once
    allows
  context the service
required to in a
    to enlist
  passed back with the
interact.
    coordination
  ReturnContext
    based on a
  message, the
    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 the previous case study example, the invoice document is attached to the
invoice header data. If the data is valid, we established the individual
   process steps
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
   internal services.
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)
                       PRODROMI
• 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
  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
  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)
                     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à).
 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
  l’orchestrazione.
             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. 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
       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.
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.
     ATOMIC TRANSACTION
• Atomic transactions implement the familiar
  commit and rollback features to enable cross-
  service transaction support ( traditional two-
  phase transaction protocol )
      Washing process example
•   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.
Atomic Transaction Protocols
• Completion
  – which is typically used to initiate the
   commit or abort states of the transaction.

• Two-Phase Commit (2PC)
            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..
Maintain to 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.
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
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.
Atomic Transaction and SOA
                 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.
                  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.   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.
     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
          tempi inaccettabili.
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.
           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
 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
  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
  specification.
• These tables establish the fundamental rules of
  the business activity protocols by determining
  the sequence and conditions of allowable states.
                  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.
                   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.
Business activity and atomic
       transactions
Business activity and SOA
                           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
          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.
• 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
                  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
   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.
Orchestration and SOA
                    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
• 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
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
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.
   – 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
             Orchestration                       Choreography
• 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
               web
                                                     service
              service




                                                 Collaboration
                                        web                       web
                                       service                   service
  web      Process flow    web
 service                  service
Choreography and SOA
              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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:2/24/2013
language:English
pages:104