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