[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Current Status of Web Services Transaction?

  • To: "xml-Dev (E-mail)" <xml-dev@l...>
  • Subject: RE: Current Status of Web Services Transaction?
  • From: "Paul Brown" <prb@f...>
  • Date: Tue, 6 Aug 2002 01:38:23 -0400
  • Cc: "Eric Lo" <ecllo@c...>
  • Thread-index: AcI8/BpGvFYtIFurQNy0MKCwtwHnnQAB7nZg
  • Thread-topic: Current Status of Web Services Transaction?

web services transaction


> -----Original Message-----
> From: Eric Lo [mailto:ecllo@c...]
>   I have read lots of materials related to Web Services transaction. [...]

Where you're really getting lost is in the meaning of a transaction.

ACID (atomic, consistent, isolated, durable -- the traditional properties of a transaction) do not apply in an asynchronous environment.  The question, which is a natural one for academically-minded people, is what is the minimal weakening of these conditions that provides a meaningful increase in utility, where minimal and maximal are defined relative to a particular space of problems.

In the context of web services, the "space of problems" is equivalent to the management of long-running transactional (in a sense to be determined) processes that consist at least partially of asynchronous invocations.  (The communications and data protocols (SOAP, GET/POST, HTTP, etc.) over and by which these invocations are made is completely irrelevant to defining or solving the problem.)

There is already a body of academic literature on the topic of long-running transactional processes (some of it venerable by the standards of XML and web services), and a reasonable treatment of approaches to the problem posedin the preceding paragraph takes about 20 pages.  (It just so happens that I am up late because I am writing a survey paper on this very subject.)

The short summary of why 2PC doesn't "work" is that either you use an enormous amount of system resources (related to open transactions), or you commit all local units of work when you make the request side of an asynchronous invocation.  The former approach (applied in general circumstances) leads to unmanageable, unscalable systems, and the latter approach provides no means to account for the circumstances where the response side of the asynchronous invocation returns an error, an unexpected response, or even an unacceptable response.  (As for what does work, the key is roll-forward as opposed roll-back...)  As above, communication and data protocols are both irrelevant.

As for BTP and its ilk, I don't know if XML-DEV is necessarily the right place to start an in-depth discussion, since we're pretty far afield from XML already.

	-- Paul

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.