RE: Web services and CORBA

Edwin, Eric:

I can go one better. We have implemented it and actually have a commercial
product available (though it is based on the BTP model, there are
differences in our (early) message set compared to the latest BTP draft). I
agree that the spec is solidly written, and though there are indeed some
practical issues that one might considering when deploying a BTP
implementation, the fact that there are existing and forthcoming
implementations means at least one of those practical issues isn't that the
spec is un-implementable :-)

As Bill Pope said earlier, we have had some fun trying to decide about
whether we are REST conformant or not. My opinion is that we aren't far off
since the message set that we have doesn't define "verbs" per se, just the
format of documents that are to be moved around, and it would be relatively
straightforward to create a binding where we'd just yank out all of the
logistical stuff from our messages and trust that to a transfer protocol
that could move stuff from A->B (in our case BTP endpoints, which are
basically just programs) for us.

Now getting an exhausted BTP committee to engage in this activity might be a
little harder ;-)

Jim

> -----Original Message-----
> From: Eric Newcomer [mailto:eric.newcomer@iona.com] 
> 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.
> 
> 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:29:25 UTC