لطفا منتظر باشید ...
Atomic Transactions
The Web services architecture has support for atomic transactions. To demonstrate this capability, we expand our sample scenario yet again. This time, before the book is generated and the BookReady message is sent from Microsoft Press, payment for the book must be confirmed. The book generation and payment verification steps are wrapped in a single transaction. The information needed to drive this logical step is included in the purchase order message. To support this scenario, we show the endpoint responsible for generating the electronic book, the Book Generator, as a separate endpoint from the Bank and from the Microsoft Press order management service.
Figure 14-1 illustrates a corresponding message flow that includes the two-phase commit protocol as implemented using WS-Atomic Transaction.
Figure 14-1. Atomic transactions with completion and two-phase commit.
[View full size image]
In summary, the School of Fine Art sends a Purchase Order to Microsoft Press. When the order is received, it is acknowledged, and requests are sent to both the Bank endpoint and Book Generator endpoint. Using the mechanisms of the architecture, these two requests are wrapped into a single atomic transaction that is managed through the Coordinator endpoint. Once the Bank service and Book Generator service notify the order management service that their processing is complete, the transaction commit process is begun by the Microsoft Press order management service. The commit process is then driven by the Coordinator service.
The exact message flow required to support this scenario is described next. This message flow shows the scenario in which the transaction completes successfully.
A PurchaseOrder [Message 1] is sent from the School of Fine Art to Microsoft Press. Its receipt is confirmed with an OrderAcknowledgement [Message 2].
The order management service then starts a new transaction by creating an appropriate coordination context and registering with the Coordinator for the Completion protocol [Message 3]. The Coordinator responds [Message 4] confirming that the participant has been registered for the transaction and noting where the coordination messages are to be sent for this participant.
Then, the order management service sends out two requests, RequestPayment [Message 5] and GenerateBook [Message 6], to the Bank and Book Generator services, respectively. In each of these messages the coordination context for the transaction is included, enabling them to be part of the transaction.
Both the Bank and Book Generator endpoints use the information present in the coordination context to register for the transaction [Messages 7 and 8] for the durable 2PC protocol. Their registrations are confirmed by the Coordinator with [Messages 9 and 10]. Note that the order of messages 7 and 8 can be inverted. Their responses need not arrive in the same order as their requests were received by the Coordinator.
Once processing completes in the Bank and the Book Generator services, each one sends an update on its status [Messages 11 and 12]. Only upon receipt of both of these messages does the order management service begin the process to commit the transaction by sending [Message 13] to the Coordinator.
When the Coordinator receives the Commit request, it will begin the traditional 2 PC (Two-Phase Commit) protocol. Each of the registered participants in the transaction is sent a Prepare message [Messages 14 and 15]. When the participants are ready commit, they respond with a Prepared message [Messages 16 and 17].
Once all of the participants have notified the Coordinator, a Commit message [Messages 18 and 19] is sent by the Coordinator to each of the participants. As a final step, each participant responds [Messages 20 and 21] to the Coordinator, and the final outcome of the transaction is communicated [Message 22] to the order management system.
When the transaction is successful, the order management services sends the BookReady message to the School of Fine Art [Message 23].
Below, we describe a selected subset of the messages. In particular, we do not show the messages corresponding to the 2PC protocol: Prepare/Prepared, Commit/Committed, exchanged between the Coordinator and the Bank and the Coordinator and the Book Generator services.
Register
The first step in the process is for the order management system to register for a transaction with the Coordinator by using the information in the coordination context.
Note
 | WS-Coordination specifies messages for an application to request that the Coordinator create the coordination context. This is an optional step, and in our example scenario, we assume that the order management system creates the coordination context on its own. |
Register
(01) <env:Envelope>
(02) <env:Header>
(03) <wsa:Action>
(04) http://schemas.xmlsoap.org/ws/2003/09/wscoor#Register
(05) </wsa:Action>
(06) ...
(07) </env:Header>
(08) <env:Body>
(09) <wsc:Register>
(10) <wsc:ProtocolIdentifier>
(11) http://schemas.xmlsoap.org/ws/2003/09/wsat#Completion
(12) </wsc:ProtocolIdentifier>
(13) <wsc:ParticipantProtocolService>
(14) <wsa:Address>http://ex.mspress.microsoft.com/Orders</wsa:Address>
(15) <wsa:ReferenceProperties>
(16) <msp:TxID>
(17) uuid:12345678-1232-2212-1234-1234123411111111
(18) </msp:TxID>
(19) </ReferenceProperties>
(20) </wsc:ParticipantProtocolService>
(21) </wsc:Register>
(22) </env:Body>
(23) </env:Envelope>
Lines 0305 The WS-Addressing Action element specifies that the Register semantics should be used to process this message.
Lines 1012 The registration is for the completion protocol defined in WS-AtomicTransaction. In our example, the second registration (for the durable 2PC protocol) uses the protocol identifier http://schemas.xmlsoap.org/ws/2003/09/wsat#Durable2PC.
Lines 1320 The endpoint reference for where coordination messages should be sent to the order management system is contained in the registration message. The specific Address and Reference Properties are different for each endpoint that registers with the Coordinator. In our example, the Register messages sent by the order management, Bank, and Book Generator endpoints are each unique in this respect.
RegisterResponse
When the transaction is successfully registered with the Coordinator, a RegisterResponse message is returned, also with an endpoint reference for processing the rest of the transaction coordination messages.
Register Response
(01) <env:Envelope>
(02) <env:Header>
(03) <wsa:Action>
(04) http://schemas.xmlsoap.org/ws/2003/09/wscoor#RegisterResponse
(05) </wsa:Action>
(06) ...
(07) </env:Header>
(08) <env:Body>
(09) <wsc:RegisterResponse>
(10) <wsc:CoordinatorProtocolService>
(11) <wsa:Address>http://ex.mspress.microsoft.com/Coord</wsa:Address>
(12) <wsa:ReferenceProperties>
(13) <msp:ContextID>%%99F02C2%%</msp:ContextID>
(14) </ReferenceProperties>
(15) </wsc:CoordinatorProtocolService>
(16) </wsc:Register>
(17) </env:Body>
(18) </env:Envelope>
Lines 0305 The WS-Addressing Action element specifies that the RegisterResponse semantics should be used to process this message.
Lines 1015 The Coordinator responds with its endpoint reference and additional information to process subsequent messages.
Line 11 The address for messages to manage this coordination context is provided.
Line 13 The application-specific Reference Property used to identify this transaction is provided.
Commit
After each of the participants in the transaction has registered for the transaction and the respective endpoints complete their processing, application-specific messages are returned to the order management system as notification of their status. In our example, the PaymentOK and BookOK messages [Messages 11 and 12] are the application-level messages used to provide this notification.
Once the application-level requirements are met, the order management system starts the process of committing the transaction. The Commit message sent to the Coordinator is a request for the Coordinator to begin the processing of the durable 2PC protocol. The Coordinator does so by sending Prepare messages to each of the transaction participants registered for the 2PC protocol.
Commit
(01) <env:Envelope>
(02) <env:Header>
(03) <wsa:Action>
(04) http://schemas.xmlsoap.org/ws/2003/09/wsat#Commit
(05) </wsa:Action>
(06) ...
(07) </env:Header>
(08) <env:Body>
...
(09) </env:Body>
(10) </env:Envelope>
Lines 0305 The WS-Addressing Action element specifies that the Commit processing semantics should be used to process this message.
The 2PC protocol messages are omitted from these examples. They are analogous to the Commit and Committed messages.
Once the Coordinator has heard from all the 2PC participants, it sends the committed message to the Microsoft Press order management system.
Committed
(01) <env:Envelope>
(02) <env:Header>
(03) <wsa:Action>
(04) http://schemas.xmlsoap.org/ws/2003/09/wsat#Committed
(05) </wsa:Action>
(06) ...
(07) </env:Header>
(08) <env:Body>
(09) ...
(10) </env:Body>
(11) </env:Envelope>
