Business activities

Business activities govern long-running, complex service activities. Hours, days, or even weeks can pass before a business activity is able to complete. During this period, the activity can perform numerous tasks that involve many participants.

What distinguishes a business activity from a regular complex activity is that its participants are required to follow specific rules defined by protocols. Business activities primarily differ from the also protocol-based atomic transactions in how they deal with exceptions and in the nature of the constraints introduced by the protocol rules.

For instance, business activity protocols do not offer rollback capabilities. Given the potential for business activities to be long-running, it would not be realistic to expect ACID-type transaction functionality. Instead, business activities provide an optional compensation process that, much like a "plan B," can be invoked when exception conditions are encountered (Figure 6.27).

Figure 6.27. A business activity controls the integrity of a service activity by providing participants with a "plan B" (a compensation).

Note

The concepts discussed in this section are derived from the WS-BusinessActivity specification, which (like WS-AtomicTransaction) provides protocols for use with WS-Coordination. The WS-Coordination overview section in Chapter 16 contains a brief example of how a coordination type referencing WS-BusinessActivity exists within a SOAP header.

In Plain English

Over time, we find that as a result of poor weather conditions, we need to cancel a number of pre-scheduled car wash appointments. Every time this happens, though, confusion ensues, as we scramble to notify each other and the customer in time.

We agree that we need some sort of system to deal with this situation. Chuck comes up with an idea. Chuck owns a house with a large garage. He volunteers his house as a location to which we can take cars for washing when it rains. We all like Chuck's idea so much, we elect him as the person responsible for assessing the weather and then determining if a particular appointment will go ahead. If it doesn't, he must notify each of us that the car will be washed at his house instead of at the customer's residence.

This essentially extends our original car washing process to incorporate a sub-process that only kicks in when certain conditions prevent us from proceeding with the initial plan. This special sub-process is classified as a compensation task or compensation process, a primary feature of business activities.

Note that the use of this compensation process does not affect the atomic transaction-like system we applied to adding soap to the bucket full of warm water. This mirrors the relationship between business activities and atomic transactions in real life; each business activity can contain one or more individual atomic transactions.

 

6.5.1. Business activity protocols

As with WS-AtomicTransaction, WS-BusinessActivity is a coordination type designed to leverage the WS-Coordination context management framework. It provides two very similar protocols, each of which dictates how a participant may behave within the overall business activity.

Business activity participants interact with the standard WS-Coordination coordinator composition to register for a protocol, as was explained in the previous Coordination section.

6.5.2. The business activity coordinator

When its protocols are used, the WS-Coordination controller service assumes a role specific to the coordination typein this case it becomes a business activity coordinator (Figure 6.28). As explained in the previous section, this coordinator has varying degrees of control in the overall activity, based on the coordination protocols used by the participants.

Figure 6.28. The business activity coordinator service model.

 

6.5.3. Business activity states

During the lifecycle of a business activity, the business activity coordinator and the activity participants transition through a series of states. The actual point of transition occurs when special notification messages are passed between these services.

For example, a participant can indicate that it has completed the processing it was required to perform as part of the activity by issuing a completed notification. This moves the participant from an active state to a completed state. The coordinator may respond with a close message to let the participant know that the business activity is being successfully completed.

However, if things don't go as planned during the course of a business activity, one of a number of options are available. Participants can enter a compensation state during which they attempt to perform some measure of exception handling. This generally invokes a separate compensation process that could involve a series of additional processing steps. A compensation is different from an atomic transaction in that it is not expected to rollback any changes performed by the participating services; its purpose is generally to execute plan B when plan A fails.

Alternatively, a cancelled state can be entered. This typically results in the termination of any further processing outside of the cancellation notifications that need to be distributed.

What also distinguishes business activities from atomic transactions is the fact that participating services are not required to remain participants for the duration of the activity. Because there is no tight control over the changes performed by services, they may leave the business activity after their individual contributions have been performed. When doing so, participants enter an exit state by issuing an exit notification message to the business activity coordinator.

These and other states are defined in a series of state tables documented as part of the WS-BusinessActivity specification. These tables establish the fundamental rules of the business activity protocols by determining the sequence and conditions of allowable states.

6.5.4. Business activities and atomic transactions

It is important to note that the use of a business activity does not exclude the use of atomic transactions. In fact, it is likely that a long-running business activity will encompass the execution of several atomic transactions during its lifetime (Figure 6.29).

Figure 6.29. Two atomic transactions residing within the scope of a business activity.

 

6.5.5. Business activities and SOA

Business activities fully complement the composable nature of SOA (Figure 6.30) by tracking and regulating complex activities while also allowing them to carry on for long periods of time. Service autonomy and statelessness are preserved by permitting services to participate within an activity for only the duration they are absolutely required to. This also allows for the design of highly adaptive business activities wherein the participants can augment activity or process logic to accommodate changes in the business tasks being automated. Through the use of the compensation process, business activities increase SOA's quality of service by providing built-in fault handling logic.

Figure 6.30. A business activity relating to other parts of SOA.

As with WS-AtomicTransaction, support of the WS-BusinessActivity extension by multiple solutions promotes inherent interoperability and can greatly simplify integration architectures. Business activities take this a few steps further, though, by allowing the scope of the activity to include interaction with outside business partners. (Note that there is nothing restricting atomic transactions from being utilized across organizations. However, business activities are typically more suitable for this type of communication.)

Case Study

The TLS Purchase Order Submission Process (illustrated in Figure 6.31) involves the TLS Purchase Order Service acting as the initial sender, responsible for transmitting a SOAP message containing PO details to the RailCo Order Fulfillment Service (Step 2). Further complicating this process is the fact that purchase orders for amounts exceeding $100,000 require a separate approval step by a TLS manager (Step 1).

Figure 6.31. The TLS Purchase Order Submission Process wrapped in a long-running business activity and spanning two organizations (two participants).

 

Vendors are given a period of 48 hours during which they are expected to check for the availability of the requested inventory and respond with either an acknowledgement message indicating that the order will be shipped or a message explaining that an order cannot be filled (or only partially filled), along with any relevant back-order information (Step 3).

Even though the PO Submission Process also can be classified as a complex activity, it is different from our previous case study example, as follows:

  • It can take a long time for this activity to complete.

  • It includes a manual review step (which can result in an approval or a rejection of the purchase order request).

To best manage this complex activity, TLS has used the same WS-Coordination context management framework applied in the previous case study example, only this time the WS-BusinessActivity coordination type is chosen instead.

SUMMARY OF KEY POINTS
  • Business activities manage complex, long-running activities that can vary in scope and in the amount of participating services.

  • WS-BusinessActivity builds on the WS-Coordination context management framework by providing two protocols for which activity participants can register.

  • Participants and the business activity coordinator progress through a series of states during the lifespan of a business activity. State transition is accomplished through the exchange of notification messages.

  • Long-running activities are commonplace in contemporary SOAs, which positions WS-BusinessActivity as an important specification for the controlled management of logic that underlies these types of complex activities.

Related

Категории