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

RE: Web services and CORBA

From: William Z Pope <zpope@pobox.com>
Date: Tue, 28 May 2002 18:12:41 -0400
To: <eric.newcomer@iona.com>
Cc: <www-ws-arch@w3.org>
Message-ID: <BMEDJOFBGLHKOHLBGALLOEPJCOAA.zpope@pobox.com>

OASIS BTP provides a protocol so that correspondents have a common 
understanding of request outcomes and provides coordination of multiple 
requests.  This is exactly the problem OASIS the committee formed to
address.  We've just hit a major milestone and the 1.0 Committee 
Specification is will be available early next week.  
https://www.oasis-open.org/committees/business-transactions/#commspec
The Committee Specification is the stable draft for public review.

BTP is designed to be protocol independent and that has caused some
difficulty with REST conformance (is there such a thing?).  BTP takes
the approach of defining its own verbs on a target actor of constrained 
type, much like web services, CORBA, DCE, ...  We are still trying to
determine how important REST is for commerce on the web and for web
services.

TIP is RFC 2371

=bill

-----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 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 18:13:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:00 GMT