Web Services Transaction Management (WS-TXM) Michael Felderer Digital Enterprise Research Institute

Web Services Transaction Management2 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 Management3 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 Management4 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 Management5 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 Management6 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 Management7 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 Management8 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 Management9 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 Management10 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 Management11 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 Management12 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 Management13 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 Management14 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