transactions with unknown duration for web services patrick sauter, ingo melzer

Transactions with Unknown Duration for Web Services

Patrick Sauter, Ingo Melzer

Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 2004

2

Research and Technology

The Problem

How to implement it? Supported by existing Web Services standards/specifications?

“unknown duration” = “long duration”?

Distributed transaction that

might be interrupted for an

unknown period of time...


3


Distributed Transactions...

Purpose: mutually agreed outcome among (business) partners

Otherwise: failed money transfer: debit without credit

Christmas trees ordered, but out of stock

overbooked airline seats


4


... for Web Services

Three competing specifications:

Web Services Composite Application Framework (WS-CAF)by Sun, Oracle, Arjuna, Iona, and Fujitsu

Business Transaction Protocol (BTP)by OASIS

Web Service Transaction Framework (WSTF)by IBM, Microsoft, BEA most likely to become widely accepted


5


Web Services Transaction Framework (IBM, Microsoft, BEA)

WS-Coordination create a new or join an existing transaction provides the CoordinationContext, e.g. unique transaction ID

WS-AtomicTransaction short-running typically: ACID, 2PC, locking in case of error: send Rollback notification

WS-BusinessActivity long-running typically: consists of several AtomicTransactions in case of error: compensate explicitly coded business logic


6


Classification of WS-AtomicTransaction and WS-BusinessActivity


7


Motivation: Bookstore Example

Participants are back-end systems


8


Bookstore Example: Human Approval

Human approval only required if not all books are available or total amount exceeds 20 €

Effective duration depends on whether user interaction is required at all and the user himself

unknown duration!


9


The Straightforward AtomicTransaction Approach

first check availability and (maybe) ask user, then lock in the meantime, another participant might snatch away the books!

unexpected error message


10


The Straightforward BusinessActivity Approach

order books (optimistic approach) in event of disapproval: compensate

return the parcel high shipping charges


11


The Need for Ready-to-Commit Timeouts

Locking resources is necessary (otherwise: unexpected errors), but

not for long (otherwise: books not available to prospective customers)

ready-to-commit (Prepared) timeouts!

Problem: Timeouts are not supported properly by WSTF


12


Workaround: “Dummy” Activity

“dummy” activity (participant) votes Rollback after 60 seconds jump back in case of late approval (61 seconds) implementation overhead


13


The “Perfect” Solution: Two Extensions of WS-AtomicTransaction

Extension 1: timeout support by bookstore coordinator timeout length determined after books have been locked

Extension 2: late approval jump back supported by dedicated error state TimeoutExpired


14


Summary

Transactions + workflow management human interaction will become more important

Transactions with unknown duration are not supported by WSTF. Proposed extensions to WS-AtomicTransaction:

timeout for the ready-to-commit phase limit on locking resources

dedicated error state TimeoutExpired enables backward jump with no unexpected error messages

Resulting implementation approach: no implementation overhead for timeout mechanism and

TimeoutExpired state


15


Thank you for your attention!


16


Backup Slide: WSTF vs. BTP

In BTP, there already is a timeout mechanism! <inferior-timeout> determines how long a participant (“inferior”) will

remain in Prepared state <default-is-cancel> if it is true: e.g. after 61 seconds,

Abort/Rollback/Compensate is assumed on both sides and no further communication is required

Still, there is no such thing as our proposed dedicated TimeoutExpired state for late approval.

(Our utilization of BTP: Deficiencies of WSTF become obvious when comparing the two specifications, but BTP still has its own problems.)


17


Backup Slide: BTP Tags that are not Part of WSTF

<btp:request-inferior-statuses .../><btp:inferior-statuses .../>

<btp:confirm-transaction .../><btp:transaction-confirmed .../>

<btpq:timeout>60</btpq:timeout> <btpq:intended-decision>cancel</btpq:intended-decision> <btp:default-is-cancel>false</btp:default-is-cancel>


18


Backup Slide: Some Advantages…

of locking: no validating checks required to confirm that the articles are still available no unexpected error messages due to the unavailability of a book

previously marked as “still available”

of timeouts: starvation-free no locks can be held forever

of our two extensions: no implementation overhead for this common scenario timeout length can be determined by the coordinator


19


Backup Slide: BusinessActivity Approach Without Shipping the Order in Completed State

Idea: Remain in state Completed (meaning “books have been reserved”); wait for user to decide; Compensate does nothing (!), while only Close starts (!) the real order process

Problem: same as locking without timeout


20


Backup Slide: The Expires Attribute of WS-Coordination

“This attribute specifies the earliest point in time at which a transaction may be terminated solely due to its length of operation. From that point forward, the transaction manager may elect to unilaterally roll back the transaction, so long as it has not transmitted a Commit or a Prepared notification.”

Feasible solution (with “may” = “actually do”), but: absolute time

assumption: clocks reasonably synchronous error state is Aborting or Ended (= “forget transaction”)

we want to jump back, i.e. not forget the transaction context determined before the transaction starts

Expires timeout length cannot be dependent on available quantity or customer loyalty

transactions with unknown duration for web services patrick sauter, ingo melzer

Documents

web services patrick

web servicespatrick

web servicesthree

long duration

notificationunknown

ingo melzertransactions

unknown period of time

case of human approval