XML Transactions for Web Services, Part 3
by Faheem Khan
|
Pages: 1, 2, 3
17. Now is the time for the PC Assembler's sales module to perform an AT for item 2. Let's suppose that some of the components required to assemble item 2 are not available in the inventory, so the AT fails this time (i.e. the AT fails to commit and gets rolled back).
18. As the AT for item 2 was not successful, so the PC
Assembler's sales module cannot send a Completed
message to the distributor's purchase module. But the PC
assembler's business logic does not want to give up an order
just because the components required to fulfill the order are
not in stock. It will try to get the components from their
corresponding vendors. Therefore it sends business activity
messages to other vendors. I have not shown the messages that
the PC Assembler sends to component vendors; the entire
messaging exchange between the PC Assembler and its vendors will
be just like the messaging between the distributor and the
assembler. You can imagine that the supply chain of this
business activity is extended to include another link, that is,
vendors that the PC Assembler wants to buy from. Let's assume
that the PC assembler's business logic is successful in sourcing
the required components from the vendors it usually buys from.
19. Now the PC assembler's sales module sends a
Completed message (for the business activity
related to item 2) to the distributor's purchase
module. This message is shown in Listing 19.
Listing 19
<?xml version="1.0"?>
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<SOAP:Body>
<wsba:Completed
xmlns:wsba="http://schemas.xmlsoap.org/ws/2002/08/wsba">
<wsba:TargetProtocolService>
<wsu:Address>
http://www.AFictitiousPCDistributor.com/WSTM/coordinationservice
</wsu:Address>
</wsba:TargetProtocolService>
<wsba:SourceProtocolService>
<wsu:Address>
http://www.AFictitiousPCAssembler.com/sales/BusinessAgreement
</wsu:Address>
</wsba:SourceProtocolService>
</wsba:Completed>
</SOAP:Body>
</SOAP:Envelope>
20--22. These steps are the same as 14, 15, and 16, but this time for item 3.
23. As readers might have already guessed, the PC assembler's sales module tries to perform an AT for item 3. Let's suppose that the AT fails again, due to unavailability of required components.
24. So the PC assembler's business logic contacts its vendors. Let's suppose the required components are not available even from the vendors.
25. Now the PC assembler knows there's no way it can fulfill the
distributor's requirement for item 3. So it sends a
Faulted message (Listing 25) to the
distributor's purchase module. A Faulted message
indicates that something went wrong while performing the
business activity and the task could not be completed.
Listing 25
<?xml version="1.0"?>
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<wsba:Faulted
xmlns:wsba="http://schemas.xmlsoap.org/ws/2002/08/wsba"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsba:TargetProtocolService>
<wsu:Address>
http://www.AFictitiousPCDistributor.com/WSTM/coordinationservice
</wsu:Address>
</wsba:TargetProtocolService>
<wsba:SourceProtocolService>
<wsu:Address>
http://www.AFictitiousPCAssembler.com/sales/BusinessAgreement
</wsu:Address>
</wsba:SourceProtocolService>
</wsba:Faulted>
</SOAP:Body>
</SOAP:Envelope>
26. The distributor's purchase module now has updates on business activities related to all the three items (items 1 and 2 are available for supply from the PC Assembler, while item 3 is not). The purchase module will present all the information for the attention of a person in charge, perhaps a Purchase Manager. The Purchase Manager will assess the scenario and make decisions regarding the items that are not available according to the purchase order. He might want to try some other vendors to check the availability of the missing items. Let's suppose that the Purchase Manager is able to locate item 3 from some alternate source, but the alternate source is offering special prices in case items 1 and 3 are purchased together (instead of just the third item). So the Purchase Manager decides to buy items 1 and 3 from the alternate source and only item 2 from the PC Assembler.
27. The distributor's purchase module sends a
Compensate message for item 1 to the PC
assembler's sales module (refer to Listing 27). The
Compensate message means that the sales module
needs to undo what it did while completing its task. Recall
from step 12 that the sales module performed an AT in order
to fulfill the requirements of the bookOrder
method call for item 1. Therefore, the sales module now
needs to undo everything that was done while performing the
AT.
Listing 27
<?xml version="1.0"?>
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<wsba:Compensate
xmlns:wsba="http://schemas.xmlsoap.org/ws/2002/08/wsba"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsba:TargetProtocolService>
<wsu:Address>
http://www.AFictitiousPCAssembler.com/sales/BusinessAgreement
</wsu:Address>
</wsba:TargetProtocolService>
<wsba:SourceProtocolService>
<wsu:Address>
http://www.AFictitiousPCDistributor.com/WSTM/coordinationservice
</wsu:Address>
</wsba:SourceProtocolService>
</wsba:Compensate>
</SOAP:Body>
</SOAP:Envelope>
28. The PC Assembler's sales module undoes the AT.
29. After undoing the AT, the PC Assembler sends a
Compensated message back to the distributor's sales
module. This is the end of story for item 1. I have shown that
the PC Assembler simply accepts this lost
business opportunity. In real world business applications, there
may be other types of compensative actions associated with such
situations.
30. The distributor's purchase module sends a Close
message for item 2 to the PC assembler's sales module. This
message is like confirming the purchase of this item and, thus,
equivalent to asking to close the business activity.
31. Recall from step 18 that the PC Assembler had engaged its vendors to get the components required to assemble item 2. The PC assembler's sales module according to its business logic finds out that in order to book this order, it needs to send confirmations to its vendors.
32. The PC Assembler's sales module sends Close
messages to its vendors corresponding to the business activity
related to item 2. I have not provided code listings to
demonstrate messaging between the PC assembler and its vendors,
but it is similar to the messaging that we have shown between
the PC distributor and the PC assembler.
33. Now the PC Assembler's sales module sends a
Closed message (Listing 33) back to the
distributor's purchase module, thus confirming that the
activity has been closed.
Listing 33
<?xml version="1.0"?>
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<!-- PCAssembler responds "Closed" message for
Item2 wrapped inside the SOAP body.-->
<wsba:Closed
xmlns:wsba="http://schemas.xmlsoap.org/ws/2002/08/wsba"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsba:TargetProtocolService>
<wsu:Address>
http://www.AFictitiousPCDistributor.com/WSTM/coordinationservice
</wsu:Address>
</wsba:TargetProtocolService>
<wsba:SourceProtocolService>
<wsu:Address>
http://www.AFictitiousPCAssembler.com/sales/BusinessAgreement
</wsu:Address>
</wsba:SourceProtocolService>
</wsba:Closed>
</SOAP:Body>
</SOAP:Envelope>
This is the end of story for this business activity for item 2. Some readers may object to ending the story with just the booking of an order, while logically this is just the start of a series of activities like manufacturing, packing, shipping etc. Well, we have ended the story only for the sake of simplicity. In actual practice, at this stage, a new child business activity will be generated for item 2, which will carry on until the order is delivered.
34. Now the distributor's purchase module sends a
Forget message (Listing 34) to the PC
Assembler's sales module for the activity related to item
3. Recall from step 25 that the PC assembler's sales module
sent a Faulted message to the distributor's purchase module
for item 3. A Forget message in response to a
Faulted message is like saying "It's all right
if you cannot perform the required activity, so just forget
the request". This marks the end of business activity
related to item 3.
Listing 34
<?xml version="1.0"?>
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<!-- Distributor sends "Forget" message for Faulted
Item3 wrapped inside the SOAP body.-->
<wsba:Forget
xmlns:wsba="http://schemas.xmlsoap.org/ws/2002/08/wsba"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsba:TargetProtocolService>
<wsu:Address>
http://www.AFictitiousPCAssembler.com/sales/BusinessAgreement
</wsu:Address>
</wsba:TargetProtocolService>
<wsba:SourceProtocolService>
<wsu:Address>
http://www.AFictitiousPCDistributor.com/WSTM/coordinationservice
</wsu:Address>
</wsba:SourceProtocolService>
</wsba:Forget>
</SOAP:Body>
</SOAP:Envelope>
An Ambiguity in the BA Specification
Before concluding this series of articles, I would like to briefly mention an ambiguity that I found while using the BA specification. This is purely my own point of view and authors of the BA specification may not agree with it.
If you look at Figure BA2 (BusinessAgreement Protocol State Diagram) and its associated explanation in section 12.1 of the WS-Transaction specification, you will notice that the diagram depicts communication between a participant and a coordinator, while the accompanying explanation discusses communication between a parent and a child. This creates confusion because a parent and its children may share the same coordinator. The BA process is effectively trying to achieve a hierarchical (parent-child) nesting of activities. In my view, the nested hierarchy should not be confused with the sequence of messages between a participant and a coordinator. These are two different concepts and should be treated independently of each other. The BA specification perhaps needs to improve on this point.
Conclusion
In this series of articles I have discussed XML-based transactions and their use in web services, demonstrating two types of XML transactions: Atomic Transactions and Business Activities. Both AT and BA represent coordinated activities. AT is an all-or-nothing activity, while BA is flexible. I have also demonstrated the use of BA on a higher level to divide the entire business logic as a hierarchy of small and easier to manage tasks. Finally, I have shown how you can represent the smallest unit of a coordinated activity as an AT.
