Web Services Transaction Management (WS-TXM)

Michael FeldererDigital Enterprise Research Institute

michael.felderer@deri.at

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