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 Tuesday, 28 May 2002 17:49:42 UTC