OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Current Status of Web Services Transaction?

[ Lists Home | Date Index | Thread Index ]
  • To: "xml-Dev (E-mail)" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Current Status of Web Services Transaction?
  • From: "Paul Brown" <prb@fivesight.com>
  • Date: Tue, 6 Aug 2002 01:38:23 -0400
  • Cc: "Eric Lo" <ecllo@csis.hku.hk>
  • Thread-index: AcI8/BpGvFYtIFurQNy0MKCwtwHnnQAB7nZg
  • Thread-topic: [xml-dev] Current Status of Web Services Transaction?



> -----Original Message-----
> From: Eric Lo [mailto:ecllo@csis.hku.hk]
>   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




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS