XML Transactions for Web Services, Part 3

In the first article of this series I introduced the idea of XML-based transactions. In the second article, I described an Enterprise Application Integration (EAI) scenario which was meant to demonstrate XML messaging in an Atomic Transaction (AT). I demonstrated how the sales module of a PC assembler interacts with inventory, database, assembly line management and accounts modules to fulfill a bookOrder method invocation request.

In this third and final article of the series, I'll discuss another type of XML transaction, the Business Activity (BA). The BA specification is included in the same WS-Transaction document that includes the AT specification.

I will extend the AT discussion of the second article to establish a case for BA and demonstrate how BA enables XML-based transactions to cross the boundaries of an enterprise and allows humans to interact with software modules and participate in real world business tasks.

An Application Scenario

Let's suppose that a distributor of PC related items wants to order some components. The distributor calls the order a purchase activity. The distributor wants to buy three of the items included in the purchase activity from the PC Assembler that we introduced in the second article. The distributor will send three bookOrder method invocation calls to the PC Assembler's sales module.

The three method invocation calls are independent of each other in the sense that the PC Assembler may opt to supply any one, two, or all three items. However, the three method invocation calls are not absolutely independent of each other, as they all relate to the same purchase activity.

The distributor wants to know whether the PC assembler can supply all the three items. The PC assembler's sales module will perform one AT (exactly as described in the second article) for each item. The outcome of the transaction will tell whether the PC assembler can supply the item or not.

If the PC Assembler has no problem supplying the three items, the distributor will confirm the order. If there are problems in any of the three items, the distributor would like to reconsider the entire purchase activity. For example, the distributor may want to contact some other supplier to ask for the availability of the three items and may eventually buy only one item from the PC assembler.

Business Activities

Try to compare this purchase activity with the bookOrder activity that we discussed in the second article. The sales module of the PC assembler tried to perform a transaction to confirm the availability of all components required to fulfill the order. The purchase order and bookOrder activities are similar in the sense that both activities need coordination across different SOAP request-response pairs. For example, the final outcome of the purchase order activity will depend upon the result of various SOAP method invocation calls.

However the purchase order activity is not totally analogous to the bookOrder scenario. There are significant differences, including the following:

1. In the bookOrder activity, we were required to confirm the availability of all components. It was an all or none requirement. If all the components were available the activity would commit, otherwise the entire activity would roll back. On the other hand, the purchase activity is more flexible. Here the distributor will ask the PC Assembler to check if the three items are available. If one or more items cannot be supplied, the distributor will analyze the scenario and may even check alternate sources before making the final decision. So the end result in the purchase activity will not look like an all or none decision. The final decision may fall somehwere in between.

2. The bookOrder activity was a completely automated operation. There was no need for any human interaction during the course of the activity. On the other hand, the purchase activity may involve human interaction. For example, there may be a Purchase Manager responsible to analyze and decide what to do if the PC Assembler cannot supply all the three items.

3. This human interaction also means that the purchase activity will have a longer life as compared to the bookOrder activity. For example, the Purchase Manager may not be immediately available when his interaction is required in the activity. So we will have to wait for the Purchase Manager to play a role.

4. The bookOrder activity never crossed the boundaries of a trusted domain. So we had no problem locking our resources. However, we cannot guarantee that the purchase order activity will always take place between organizations that enjoy a high level of trust for each other. For example, the distributor may also ask the availability of some items from vendors that are new to him, thus bringing those new organizations within the scope of a BA.

Thus, the purchase order activity is a coordinated activity just like the bookOrder activity was. However, the two activities are not exactly the same and they have several fundamental differences. These differences provide the basic rationale for defining a flexible type of coordinated activity that allows partly committed and partly rolled-back operations, that is longer lived, and that allows us to cross the boundaries of trusted domains. The Business Activity (BA) as defined by the WS-Transaction specification is an attempt to define an XML-based mechanism for such coordinated activities.

The four differences between the purchase and bookOrder activities mentioned above do not form the complete basis for defining the BA process. There is one more fundamental reason for it. Business Activities allow nested activities, which means that we can create activities that have parent-child relationship with each other. There can be any number of nesting levels.

For example, if we consider the aforementioned application scenario, the overall purchase activity can be considered as a parent activity, while there can be a number of child activities, one for each item. This concept is shown graphically in Figure 1, which illustrates the fact that the parent purchase activity consists of many child activities, where each child represents the purchase of a single item. Notice that each child activity may further consist of one or more ATs. The next section of this article will demonstrate the actual exchange of messaging that accomplishes this.

Figure 1. A Parent BA May Consist of Child Activities

You can think of each BA as a scope. The child activities will live within the scope of their parent. For example, the BA related to a single item will be valid only within the scope of the parent purchase activity. Also notice that the purchase activity will depend on the outcome of activities related to individual items. For example, the overall purchase activity will depend on whether the PC Assembler can or cannot supply the three items that the distributor requires from him. Thus, the concept of BA enables the breaking of a business process into a hierarchy of smaller and more manageable tasks. This provides another reason for the Business Activity process.

Exchange of Messages in Business Activities

A new BA is created using the same WS-Coordination activation service that we demonstrated in the second article. Similarly, the participants will also register their roles using the WS-Coordination registration service. There are two possible roles that a participant can assume in a BA. For each role the WS-Transaction specification defines a protocol.

I have provided a graphical illustration of the activities that take place during the execution of the purchase BA in Figure 2. Notice that there are three participants (actors) in the purchase order business activity: the distributor's purchase module, the distributor's coordinator, and the PC assembler's sales module. The distributor's purchase module and the coordinator are two distinct modules that belong to the distributor's enterprise implementation. However, for the PC assembler's sales module, the other two participants (the distributor's purchase module and the coordinator) appear to be the same actor, as the two participants belong to the same enterprise.

Figure 2. Exchanging Messages During the Course of a BA

All messages are shown as numbered arrows in Figure 2 and explained below:

1. The distributor's purchase module initiates the purchase activity by requesting the activation service of the coordinator to create a new BA. The purchase module sends a CreateCoordinationContext request as shown in Listing 1 to its coordinator's activation service.

Pages: 1, 2, 3

Next Page