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

RE: Web services and CORBA

From: Peter Furniss <peter.furniss@choreology.com>
Date: Thu, 30 May 2002 09:45:53 +0100
To: <eric.newcomer@iona.com>, "Edwin Khodabakchian" <edwink@collaxa.com>, <www-ws-arch@w3.org>
Message-ID: <LLEBILBKKFJFAFMCFCHJOECJDGAA.peter.furniss@choreology.com>

We (Choreology) agree with Jim that BTP is implementable, which is why we
are implementing it !

Eric and others have already mentioned some of the important points of BTP.
One that hasn't been emphasized is that BTP is designed as independent of
the underlying carrier. So the mapping to SOAP/HTTP that we have in the 1.0
spec is the first rather than the only. There is a "carrier binding
proforma" that defines what has to be stated to use BTP over another
carrier, which expects that fields and messages whose semantic or function
is already provided by the carrier are omitted.

On 2PC applicability to the Web, the fundamental axiom of BTP is that the
interaction between parties is a matter of contract (for a very wide
understanding of "contract") and this includes what happens if the proposed
work is confirmed or cancelled. In this view, the classic database approach
of locking everything else out, and then either unlocking the changes or
reverting the (remembered) original is just one possible implementation
approach for delivering on a contract to make changes that are subject to
confirmation or cancellation. Compensation (= doing it all but remembering a
way to undo it) - and "check-and-keep" (= store what to do but don't really
do it till confirmed) - are equally valid.  The key is that I don't care
what you do with your data; but I do care that you won't bill me until and
unless I confirm.

More comments in line:

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Eric Newcomer
> Sent: 29 May 2002 12:14
> To: Edwin Khodabakchian; www-ws-arch@w3.org
> Subject: RE: Web services and CORBA
> Edwin,
> It's a good spec.  I've been tracking it since the summer, and I assigned
> Pyounguk Cho to work on it for us.  It's based on classic
> principles, which
> may or may not help its adoption -- this will be the big question going
> forward.
> It's based on the "two pipe" model, like TIP and TxRPC before it,
> but avoids
> tying the transaction outcome to specific resource manager
> operations.  This
> is both a strength and a weakness -- strength because this is what most
> people mean when they say 2PC (or classic ACID) isn't practical over the
> Web -- holding database locks open on multiple resources over the
> Web would
> have significant performance consequences.  But it's a weakness
> (although of
> course necessary) because it can't guarantee recovery.

Do you mean that non-isolation approaches don't always work - which is true,
since something may have got in and made sufficient changes that either the
compensation or the original, stored changes won't work.  But BTP does have
full recovery to ensure delivery of the decision - so if the service
implementor can work out how to deliver the right effect when the outcome is
eventually delivered, it can be as recoverable as you like. BTP does expect
the BTP actors to recover (as Eric refers to in the next paragraph), even if
something has taken liberties with the data they were supposed to be

> The main benefit is that it reliably notifies multiple participants of a
> transaction outcome, meaning that at least everyone enrolled in the
> transaction knows what happened to everyone else.
> The BTP model relies on the transaction initiator to enroll other
> participants, and

that depends a bit on the application+BTP arrangements. The initiator will
need to propagate the BTP identification in way that the receiving
application expects, but it is up to that receiving application to actually
decide to enroll a participant(s) (thus allowing the receiver to decide how
to structure its work.)

>                   for each participant in a BTP message exchange to
> coordinate BTP messages with application messages (consistent with the two
> pipe model), and there would be some practical questions around the
> performance of that -- sending all the messages -- as there would be with
> any solution.

BTP isn't quite as strictly two-pipe as TIP, and can ameliorate the
performance costs. BTP allows for so-called "one-shot" optmisation, where
the BTP messages travel with the application message (in headers or
whatever) - so one network round trip means the participant is enrolled and
prepared, waiting for the outcome message - which will be another round trip
sent once the coordinator has decided if it is yes or no for this


Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

> But the spec itself is very solid, well written, technically
> consistent, and
> should be implementable.  IONA supports it, definitely, although I think
> there are some practical issues to be explored.
> Eric
> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Tuesday, May 28, 2002 6:09 PM
> To: eric.newcomer@iona.com; www-ws-arch@w3.org
> Subject: RE: Web services and CORBA
> Eric,
> Given your extensive background in transaction management and
> distributed computing, what do you think about BTP?
> Thank you,
> Edwin
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
> Behalf Of Eric Newcomer
> Sent: Tuesday, May 28, 2002 1:46 PM
> To: eric.newcomer@iona.com; bhaugen; www-ws-arch@w3.org
> Subject: RE: Web services and CORBA
> ps -- about the SOAP-TIP mapping draft, it was never published...so no
> URI!
> -----Original Message-----
> From: Eric Newcomer [mailto:eric.newcomer@iona.com]
> Sent: Tuesday, May 28, 2002 5:35 PM
> To: bhaugen; www-ws-arch@w3.org
> Subject: RE: Web services and CORBA
> Yes, this is exactly the sort of thing I was looking for, and it's
> definitely on the right track for characterizing the problem.  Thanks!
> I think you were referring to the Tentative Hold Protocol Note?
> http://www.w3.org/TR/tenthold-2/
> The trouble in this type of protocol is guaranteeing recovery from
> failure, i.e. one party can end up thinking the order was processed but
> not the other.
> Anyway, there's no solution to this problem over the Web yet, at least
> not that I've seen.
> Thanks again,
> Eric
> -----Original Message-----
> From: bhaugen [mailto:linkage@interaccess.com]
> Sent: Tuesday, May 28, 2002 4:18 PM
> To: eric.newcomer@iona.com; www-ws-arch@w3.org
> Subject: Re: Web services and CORBA
> Eric Newcomer  wrote:
> > Thanks -- but the point I was really trying to make is that the
> discussion
> > has not yet been extended to how to map onto the underlying business
> systems
> > that implement the logic.
> [...]
> > As you correctly point out, the Web isn't very suitable to traditional
> > two-phase commit transaction protocols.  Maybe a kind of "latch"
> mechanism
> > such as you suggest, and as exists in some message queuing systems
> (compare
> > the state on both ends) can provide a partial solution.
> "Latch" still sounds too database-oriented, but maybe it's moving in the
> correct direction.
> The following is a trial baloon.  Please tell me if it comes closer to
> the kind of discussion you seek:
> Once I read a pattern called Proposal.  Can't find the URL now. The idea
> was that things like Orders which are not yet accepted should be kept
> out of the underlying and official business system until they were
> accepted.
> So for example in a P2P order-acceptance "transaction",
> the order would remain a Proposal at both ends until
> it was clearly accepted.
> If the seller needed to place some dependent demands
> on component suppliers (as in the Dell story) they could
> be nested "transactions" of the same kind - maybe using something like
> the "temporary hold" idea.
> If all the required components were available, the seller
> could accept the original order and then cash in the
> "temporary hold" coupons for the components.
> In all cases, there is a pretty simple two-party offer-acceptance
> state-alignment "transaction" going across trust boundaries.
> The "Proposal" objects get written to the internal
> business systems after the external "transactions"
> are completed.
> Using "temporary holds" or "soft allocations with
> time constraints" for resources like inventory or
> schedule slots would seem to be a necessary
> corollary.
> Does this work for you?  Where do you forsee trouble?
> Is it at least getting into the kinds of problems you
> want to discuss?
> > I encountered this more than two years ago when sketching out SOAP-TIP
> with
> > Don Box (a mapping of SOAP to the Transaction Internet Protocol) --
> because
> > the TIP messages required a connection-oriented protocol, it was
> obvious the
> > problem was larger than simply carrying TIP primitives in SOAP headers
> and
> > defining a schema for them.
> I searched for a reference to this work, but didn't find much. Got an
> URL?
> Thanks for the conversation,
> Bob Haugen
Received on Thursday, 30 May 2002 04:46:46 UTC

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