Transactions with Unknown Duration for Web Services Patrick Sauter, Ingo Melzer

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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...

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October Classification of WS-AtomicTransaction and WS-BusinessActivity

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October Motivation: Bookstore Example Participants are back-end systems

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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!

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October The Straightforward BusinessActivity Approach order books (optimistic approach) in event of disapproval: compensate  return the parcel  high shipping charges

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October Workaround: “Dummy” Activity “dummy” activity (participant) votes Rollback after 60 seconds jump back in case of late approval (61 seconds) implementation overhead

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October Thank you for your attention!

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October Backup Slide: WSTF vs. BTP In BTP, there already is a timeout mechanism!  determines how long a participant (“inferior”) will remain in Prepared state  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.)

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October Backup Slide: BTP Tags that are not Part of WSTF 60 cancel false

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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

Research and Technology Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 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