1 / 20

Transactions with Unknown Duration for Web Services

Transactions with Unknown Duration for Web Services. Patrick Sauter, Ingo Melzer. The Problem. How to implement it? Supported by existing Web Services standards/specifications? “unknown duration” = “long duration”?.

kaycee
Download Presentation

Transactions with Unknown Duration for Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

  7. Motivation: Bookstore Example • Participants are back-end systems Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 2004

  8. Bookstore Example: Human Approval Human approval only required if • not all books are available or • total amount exceeds 20 €  unknown duration! Effective duration depends on • whether user interaction is required at all and • the user himself Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 2004

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

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

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

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

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

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

  15. Thank you for your attention! Transactions with Unknown Duration for Web Services - Patrick Sauter, Ingo Melzer - Berliner XML-Tage - 11 October 2004

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

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

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

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

  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 Commitor 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 - Berliner XML-Tage - 11 October 2004

More Related