W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

Re: Web services and CORBA

From: Mark Baker <distobj@acm.org>
Date: Thu, 30 May 2002 23:50:13 -0400
To: Peter Furniss <peter.furniss@choreology.com>
Cc: www-ws-arch@w3.org
Message-ID: <20020530235013.E2538@www.markbaker.ca>

On Thu, May 30, 2002 at 04:03:53PM +0100, Peter Furniss wrote:
> That's what I meant about following the letter but not the spirit. And it's
> the two-phase nature of
> application contract that is the problem - BTP just provides the support for
> that.

I would expect that 2PC is essential in the case where reaching or
approaching ACID is required.  I would also expect that this would be
the case where the parties involved have a pre-existing trusted

But I'm personally more interested in the problem of how one coordinates
any type of transaction between untrusted, uncoordinated parties.
Hopefully that solution would be able to be used to approach hard core
ACID style semantics, but I wouldn't count that a critical success
factor.  Worst case, if this doesn't work out, then the previously
coordinated parties can agree to use a different protocol as part of
their previous coordination. 8-)

> > I personally think the Tentative Hold Protocol has more the type of
> > coordinating semantic that is suitable between untrusted parties.  But
> > IMO it would be more suitable and useful as an HTTP extension rather
> > than as a SOAP app.
> In THP (if I understood it right), there isn't any promise made as to
> whether the "hold" will
> still be there when you go back. So having tentatively held A, and then B,
> the clients says yes to both - only to discover that A got pre-empted and
> the hold didn't actually mean anything. If you want consistency, someone has
> to pass through a pending state, dependent on the decision being made
> elsewhere.


> Fundamentally, the purpose of a business transaction (small b, small t), is
> to achieve a consistent and coordinated change in the state of a business
> relationship as perceived by the involved parties. Just before the decision
> that makes that change occurs (which can only be at one point), the other
> party(s) are waiting on that decision, which is a stateful relationship.

Aside; "stateful" in this case seems to imply a stateful service, rather
than a stateful interaction with a service.  FWIW, I was earlier talking
about the latter, not the former.

> You may be able to juggle the protocols a bit (making it url's all the way
> down for example), but there is still a shared transient state between them
> (in addition to the eventual shared state if the transaction confirms).


> > (being able to free up resources quickly) and relative immunity to
> > partial failures, but as we've seen with cookies, you can maintain many
> > of the advantages of REST while being stateful.
> If the cookie is actually a reflection or reference to information held, for
> this relationship, on the server, it's actually a stateful relationship with
> paint on it.

Right.  I think I said that.

> BTP does recognise the scalability issues and the need to release
> resources - a BTP participant can set a time-limit on how long it will wait
> for the decision. It then inevitably risks the same problems as for THP,
> mentioned above, but at least there was a warning.

THP still allows for consistency, because you do receive unambiguous
information as to whether the lock was held or not.  The problem is
obviously that the probability of not having the hold when you thought
you did, is not insignificant.  That's why I don't think THP is
sufficient as a general solution.

I suggest we take this offline, or to another archived forum.  If we
come to any conclusion, we can report back.

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Thursday, 30 May 2002 23:41:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:56 UTC