Section 11.4. Example


11.4. Example

11.4.1. Travel Agent Scenario Using Atomic Transaction

The following example illustrates a travel agent scenario modeled using the atomic transaction protocol (WS-AT). In this simple scenario, the travel agent processes a travel reservation that includes booking an airline flight, hotel accommodation, and car rental. The completed reservation includes all three bookings (see Figure 11-21).

Figure 11-21. Atomic transactionstravel scenario.


Activation

The travel agent application creates a transactional activity by using the WS-Coordination framework's Activation Service. It does this by sending a CreateCoordinationContext request to the Activation Service. The Coordination Service returns a Coordination Context that uniquely identifies the transaction and includes the address of the Registration Service.

Application Calls Web Service

The application then performs operations on Web services. The Coordination Context obtained earlier is passed along as a SOAP Header on application calls to the various Web services to identify the activity that is associated with the operation (illustrated in Figure 11-22).

Figure 11-22. Atomic transactionstravel scenarioapplication message passes CoordinationContext.


Registration

The first time that a Web service processes a CoordinationContext, it issues a register to the WS-Coordination framework's Registration Service by using the Registration Service address obtained from the CoordinationContext. It passes the participant's address that is to be used for the subsequent AtomicTransaction protocol messages[2], as illustrated in Figure 11-23. The Registration Service acknowledges the registration and returns the coordinator's address. This address will be used to drive the transaction protocol or notify the coordinator in the event of a fault or recovery condition.

[2] Alternatively, the target can choose to create a subordinate coordinator (using a create operation specifying a coordination context of the superior coordinator). The subordinator coordinator registers with the coordinator specified on the received coordination context and the resource registers with the subordinate coordinator.

Figure 11-23. Atomic transactionstravel scenarioregistration.


The Web service(s) performs the operation and returns results.

Note that the CoordinationContext can also be included on the application response so that information can be returned in the context extension element. Certain transaction implementations exploit the ability to return implementation-specific information.

Completion/Coordination

The application completes the activity. After assuming that everything is satisfactory, the application issues a Commit (AtomicTransaction/2PC protocol) message on the coordinator.

The coordinator performs the transaction agreement protocol for which the Web service(s) registered (in this scenario, the 2PC protocol). The protocol solicits the resource status via Prepare, and then it transmits a final outcome, either a Commit or Rollback (2PC protocol) message, to each resource that registered. The Participant address that was sent during registration locates the correct Resource instance to be Committed or Aborted. The Web service votes positively for the two-phase commitment protocol and returns Prepared to the coordinator (illustrated in Figure 11-24).

Figure 11-24. Atomic transactiontravel scenarioPhase 1.


The coordinator collects all the votes and determines that the transaction can be committed or aborted. For a successful transaction, the Coordinator sends Commit to the participant Web services. The Web service acknowledges the commitment message and returns Committed to the coordinator (as illustrated in Figure 11-25).

Figure 11-25. Atomic transactiontravel scenarioPhase 2.


11.4.2. Travel Agent Scenario Using Business Activity

The following example illustrates a travel agent scenario modeled using the Business Activity protocol (WS-Business Activity), shown in Figure 11-26.

Figure 11-26. Business activitytravel scenario.


This example exercises the same travel agent scenario that illustrates atomic transactions. However, the example has been modified to illustrate the following:

  • Relaxed atomicity The Web services accessed during the transaction can be selectively included in the overall application outcome.

  • Relaxed isolation Web services complete the application requests and expose the result outside the transaction.

  • Compensation Web services provide additional outcome processing if the overall application fails to reverse operations that are exposed outside the transaction.

  • Simplified modeling Employing a parent-child relationship between the application and Web services allows a clear separation of business logic versus completion processing.

Activation

The travel agent application creates a transaction for the business activity by using the WS-Coordination framework's Activation Service. The CreateCoordinationContext request is sent from application to the Activation Service and the Coordination Service returns a CoordinationContext that uniquely identifies the Business application. As outlined for atomic transactions, the application registers using the Registration Service that is specified in the Coordination Context:

  • The application defines itself as responsible for driving the Completion protocol to complete the activity.

  • The Coordinator Service address is returned on the call that the application uses to invoke the Completion protocol.

The application then uses the existing transaction to create a parent-child relationship between the application and the Web service it is about to invoke. The Coordination Framework's Activation Service provides an optional extension of Create to indicate the NestedCreate that allows this.

The CreateCoordinationContext request is sent from an application to the Activation Service. The Coordination Service returns a CoordinationContext that the parent application uses to uniquely identify the child Web service. The CoordinationContext is used on subsequent calls to the Web service(s).

Application Calls Web Service

The application performs a business operation (eg, to book a hotel room) supported by a Web service.

The message sent includes a CoordinationContext SOAP Header for the business transaction that the Web service will use (see Figure 11-27).

Figure 11-27. Business activitytravel scenarioapplication message passes coordination context.


Registration

The first time that a Web service processes a CoordinationContext, it issues a Register to the WS-Coordination framework's Registration Service. It does this by using the Registration Service address from the CoordinationContext. It passes the Participant's address to be used for subsequent BusinessActivity protocol messages.

The Registration Service acknowledges the registration and returns the Coordinator address (which drives the transaction protocol) or notifies the Coordinator in the event of a fault or recovery condition. The Web service(s) performs the operation and returns results (see Figure 11-28).

Figure 11-28. Business activitytravel scenarioregistration.


Note that the CoordinationContext can also be included on the application response to allow information to be returned in the extension element. Certain transaction implementations exploit the ability to return implementation-specific information.

Web Service Completion

The Web service(s) performs the application request and indicates that it is finished with processing by sending a Completed message to the coordinator. At this point, the Web service results might be exposed outside the transaction if other applications invoke the same Web service (see Figure 11-29).

Figure 11-29. Business activitytravel scenarioWeb service completion.


Coordination

Based on the Completed message, the application determines that all the Web services have been successful. Based on the customer itinerary, the travel agent decides to cancel the rental car and book the flight and hotel:

  • The application rejects the transaction to the rental car Web service, which triggers the Coordination service to compensate that child transaction.

  • The application accepts transactions to airline and hotel Web services, which triggers the Coordination service to close the child transactions.

The Web services respond appropriately (Compensated or Closed, as illustrated in Figure 11-30).

Figure 11-30. Business activitytravel scenariotransaction outcome.


Using nested parent-child relationships is a recommended application pattern. Such an approach facilitates the construction of scenarios that include selective inclusion of Web service results within an overall application outcome. Removal of a child from the parent transaction processing as defined by nesting rules dictates that other children are unaffected when a sibling is excluded in this fashion. This greatly simplifies the recovery processing logic that is required when dealing with these types of scenarios.

Completion processing alternatives exist if a Web service exploits the additional features that the WS-BusinessActivity protocol provides. For example, the Web service in the previous example might define the reservation request to remain pending subject to explicit confirmation or cancellation from the application. In that case, the Web services would not return Completed immediately. A reservation cancellation would trigger the Web service to remove itself from the transaction via Exit (illustrated in Figure 11-31).

Figure 11-31. Business activitytravel scenarioWeb service cancellation.


The child transaction that is executing at the Web service could also be an atomic transaction (rather than a business activity). In this case, the application aborts the child to remove it from parent transaction processing. As defined by transaction nesting rules, other children are unaffected when a sibling is removed in this fashion.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net