Examples of a Coordinated Process

So far, this chapter may seem fairly abstract. To try to make things a little clearer, let s take a look at some hypothetical examples of how WS-Coordination and WS-AtomicTransaction can enable some simple but realistic coordinated processes. In the simplest case, 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 at http://example.com/MyOrderService that receives orders for products

• An inventory service at http://example.com/MyInventoryService that provides inventory information from a warehouse

• A shipping service at http://example.com/MyShippingService that schedules shipments

• A coordinator service at http://example.com/MyCoordinator 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. The process, which is shown in Figure 7-3, goes as follows:

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.

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.

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.

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.

    
    Figure 7-3: Example of a coordinated transaction