by Thomas Erl
Business activities consist of long-running, complex transactions involving numerous services. 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 the rules of specific 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.
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.
- The Business Agreement With Participant Completion protocol, which allows a participant to determine when it has completed its part in the business activity.
- The Business Agreement With Coordinator Completion protocol, which requires that a participant rely on the business activity coordinator to notify it that it has no further processing responsibilities.
Business activity participants interact with the standard WS-Coordination coordinator composition in order to register for a protocol, as was explained in the previous Coordination section.
The Business Activity Coordinator
When its protocols are used, the WS-Coordination controller service assumes a role specific to the coordination type – in this case it becomes a business activity coordinator. 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.
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.
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.
Implementing a WS-BusinessActivity Coordination Type
The specific protocol(s) that establish the rules and constraints of a service activity within WS-Coordination are identified within the CoordinationType element. The URI values that are placed here are predefined within the WS-BusinessActivity specification.
This example shows the CoordinationType element containing the WS-BusinessActivity coordination type identifier. This would indicate that the activity for which the header is carrying context information is a potentially long-running activity.
- The WS-Coordination Context Management Framework
- Cross-Service Transactions with WS-AtomicTransaction
- Long-Running Transactions with WS-BusinessActivity
- An Overview of the WS-Security Framework
- Service-Oriented Business Processes with BPEL
- Building a Communications Framework with WS-Policy and WS-ReliableMessaging
- Defining the Web Service with WSDL
- An Inside Look into SOAP Messaging
- UDDI In and Out of the Enterprise
- A W3C Web Services Glossary
- Understanding WS-Policy Part I: Operator Composition Rules and Attachments
- Understanding WS-Policy Part II: Operator Composition Rules and Attachments
- Web Service Contract Versioning Fundamentals Part I: Version Identifiers and Versioning Strategies
- Web Service Contract Versioning Fundamentals Part II: Version Identifiers andVersioning Strategies
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
For more information about these books, visit: www.servicetechbooks.com