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

RE: Web services and CORBA

From: Edwin Khodabakchian <edwink@collaxa.com>
Date: Tue, 28 May 2002 15:08:42 -0700
To: <eric.newcomer@iona.com>, <www-ws-arch@w3.org>
Message-ID: <001501c20694$3ab03c70$670aa8c0@collaxa.net>
Given your extensive background in transaction management and
distributed computing, what do you think about BTP?
Thank you,

-----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

-----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?


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,


-----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
> has not yet been extended to how to map onto the underlying business
> 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"
> such as you suggest, and as exists in some message queuing systems
> 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

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

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
> Don Box (a mapping of SOAP to the Transaction Internet Protocol) --
> the TIP messages required a connection-oriented protocol, it was
obvious the
> problem was larger than simply carrying TIP primitives in SOAP headers
> defining a schema for them.

I searched for a reference to this work, but didn't find much. Got an

Thanks for the conversation,
Bob Haugen
Received on Tuesday, 28 May 2002 18:09:17 UTC

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