by Thomas Erl 		 WS-* Specifications
divider
 Long-Running
 Transactions with
 WS-BusinessActivity
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 BusinessAgreementWithParticipantCompletion protocol, which allows a participant to determine when it has completed its part in the business activity.
• The BusinessAgreementWithCoordinatorCompletion 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.
 

return to homepage


SOA Design Patterns
by Thomas Erl

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.


Web Service Contract Design & Versioning
for SOA
by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley




SOA Principles
of Service Design
by Thomas Erl

An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation).


Service-Oriented Architecture:
Concepts, Technology, and Design
by Thomas Erl

The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design.
Service-Oriented Architecture:
A Field Guide
to Integrating
XML and Web Services
by Thomas Erl

The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices.

For more information about these books, visit: www.soabooks.com

SOA Certified Professional

The books in this series are part of the official curriculum for the SOA Certified Professional program.

For more information:

•  www.soacp.com

•  www.soaschool.com



   
   

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.
<wsc:CoordinationType>   http://schemas.xmlsoap.org/ws/2004/01/wsba </wsc:CoordinationType>
To learn more about WS-BusinessActivity, view the specification by visiting www.soaspecs.com

   
   
Home   Copyright © 2003-2009 SOA Systems Inc.