Web Services Transaction Management (WS-TXM)
Michael FeldererDigital Enterprise Research Institute
http://developers.sun.com/techtopics/webservices/wscaf/wstxm.pdf
Web Services Transaction Management 2
Assumptions
• ACID transactions implicitly assume– Closely coupled environment– Short-duration activities
• WS based B2B communication often involves– long running computations– loosely coupled systems– components that do not share data and location
Web Services Transaction Management 3
Two-phase commit (2PC)
prepare phase: participants that can commit are required to allow completion if failure
commit/rollback phase: coordinator records sufficient information to complete in case of failure
Web Services Transaction Management 4
Architecture
WS-TXM defines a set of pluggable transaction protocols that can be
used with the coordinator to negotiate actions for all participants
to coordinate the execution of related WS.
The executions are related through the use of shared context
Web Services Transaction Management 5
Transaction Models
WS-TXM defines three transaction models that address different use cases:
• ACID transaction
• Long running action
• Business process transaction
WS-TXM specification is a live document: new models can be added as required
Web Services Transaction Management 6
ACID Transaction (TXACID)
• each activity is bound to the scope of a transaction, such that the end of an activiy triggers the termination (commit or rollback) of the associated transaction
• not suitable for all WS, but e.g. for high-value interactions such as those involved in finance
• can be used to bridge between proprietary transaction service implementations
Web Services Transaction Management 7
Long Running Transaction (TX-LRA) (1)
• LRA is designed specifically for those business interactions that occur over a long duration
• all work performed withing the scope of an application should be compensatable. Therefore, an application's work is either performed successfully or undone. How individual WS perform their work and ensure it can be undone (if compensation is required) is implementation choice. LRA only defines the triggers for compensation actions.
• LRA defines a protocol actor called a compensator that operates on behalf of a service to undo the work it performs within the scope of an LRA
Web Services Transaction Management 8
Long Running Transaction (TX-LRA) (2)
• Services may entlist compensator participants within the LRA coordinator.
• The coordinator will send the compensator one of the following messages when the activity terminates:– success: activity has completed successfully– fail: activity has not completed; all compensators
that are registered will be invoked to perform compensation in reverse order
Web Services Transaction Management 9
LRA: Example
All individual activities are compensatable
If the booked taxi is not accepted , the work of the other activities will
be undone
If the booking completes successfully, any compensation
mechanism passes to LRA5 and frees the resources of LRA1
Web Services Transaction Management 10
Business Process Transaction (TX-BP)
• TX-BP is specifically aimed at tying heterogeneous transaction domains together into a single business-to-business transaction.
• It may be structured as collection of atomic transactions or long running actions depending upon application requirements
• all tasks reside within business domains that checkpoint their state so that they can either be consistently rolled back or restarted from the checkpoint in the event of failure
Web Services Transaction Management 11
BP: Example
Each supplier resides in ist own business domain. The user may interact synchronously with the travel agent or may submit an order to the agent. Business domains are instructed to perform work within the scope of a global business process. The business process has an overall manager that may be informed by individual tasks when they have completed their work or it may periodically communicate with each task to determine its current status.
Web Services Transaction Management 12
Alternative Specs for WS Transaction Management
OASIS-BTP:• first standard attempt (HP, Sun BEA, Oracle and others)• defines two transaction models (atoms, cohesions)• does not address transaction interoperability• already implemented by HP, Choreology, Collaxa etc.
WS-C/T• proprietary specification released by IBM, Microsoft and BEA• separates coordination from transaction• define two transaction models (atomic transaction, business activities)• simplicity and interoperability with existing protocols play key role
Web Services Transaction Management 13
BTP vs. WS-T vs. WS-TXM (1)
The most striking feature is that each offers different transaction models at the uppermost layers, but it is important to note that the WS-Coordination layer in the WS-T/C stack is also available for applications to build on. In the WS-CAF stack, the WS-Context layer is also exposed for use.
Web Services Transaction Management 14
BTP vs. WS-T vs. WS-TXM (2)
• BTP is not interoperable therefore real issue seems to be between WS-T and WS-TXM
• WS-CAF has been designed to plug in WS-C/T• WS-CAF is royalty free (WS-C/T not)• All of the existing specifications use the same
fundamental two-phase outcome principles, either explicitly or implicitly
• Past:ACID; Present: BTP, WX-T,WS-TXM Future: Merge the last two