Web Services Transaction Management (WS-TXM)

1
Web Services Transaction Management (WS-TXM)
http//developers.sun.com/techtopics/webservices/w
scaf/wstxm.pdf

• Michael Felderer
• Digital Enterprise Research Institute
• michael.felderer_at_deri.at

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

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
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
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

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

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

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

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
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

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.
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

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.
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
• PastACID Present BTP, WX-T,WS-TXM
• Future Merge the last two