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.

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

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 Wednesday, 29 May 2002 07:18:35 UTC