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

Re: Web services and CORBA

From: Mark Baker <distobj@acm.org>
Date: Thu, 30 May 2002 09:45:35 -0400
To: Peter Furniss <peter.furniss@choreology.com>
Cc: "WEBBER,JIM HP-UnitedKingdom,ex1\"" <jim_webber@hp.com>, www-ws-arch@w3.org
Message-ID: <20020530094535.F15574@www.markbaker.ca>

Hi Peter.

On Thu, May 30, 2002 at 09:45:55AM +0100, Peter Furniss wrote:
> On the question of BTP's alignment with REST, although it might be possible
> to have a BTP "carrier" binding that was REST-aligned, I think that might in
> fact be following the letter of REST while contradicting the spirit.
>
> The whole point of BTP is to establish a stateful relationship between
> multiple parties, so that if the coordinating entity can determine that a
> consistent solution is possible, it can say to the parties "confirm the
> operation I told you about before".  After that confirm is sent, the
> stateful relationship ends.

Right.  I think that the existing stateful relationships in BTP could
be quite easily refactored to be stateless, by creating resources that
identified the transaction itself.  But the 2PC nature of BTP would
seem to me to be an issue for Internet-scale deployment.

I personally think the Tentative Hold Protocol has more the type of
coordinating semantic that is suitable between untrusted parties.  But
IMO it would be more suitable and useful as an HTTP extension rather
than as a SOAP app.

> You need to have that stateful relationship if there is to be any consistent
> decision over multiple parties.

Well, you need to have a coordinating relationship.  It doesn't have to
be stateful.

> If two are to agree, it is inevitable that
> at some point at least one party will be in a condition where it has made
> itself subject to someone else's decision. You can squeeze, transfer and
> juggle this, but it won't go away. (A "completed" but
> could-still-be-compensated operation is still such a condition).
> 
> I'm not sure how that fits with the requirement of statelessness in REST
> (which I perceive as being more central to REST than specifics about GET and
> POST).

Stateless interactions are important for reasons such as scalability
(being able to free up resources quickly) and relative immunity to
partial failures, but as we've seen with cookies, you can maintain many
of the advantages of REST while being stateful.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Thursday, 30 May 2002 09:37:19 GMT

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