RE: Web services and CORBA

Mark Baker sent:


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

That's what I meant about following the letter but not the spirit. And it's
the two-phase nature of
application contract that is the problem - BTP just provides the support for
that.

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

In THP (if I understood it right), there isn't any promise made as to
whether the "hold" will
still be there when you go back. So having tentatively held A, and then B,
the clients says yes to both - only to discover that A got pre-empted and
the hold didn't actually mean anything. If you want consistency, someone has
to pass through a pending state, dependent on the decision being made
elsewhere.

Fundamentally, the purpose of a business transaction (small b, small t), is
to achieve a consistent and coordinated change in the state of a business
relationship as perceived by the involved parties. Just before the decision
that makes that change occurs (which can only be at one point), the other
party(s) are waiting on that decision, which is a stateful relationship.
You may be able to juggle the protocols a bit (making it url's all the way
down for example), but there is still a shared transient state between them
(in addition to the eventual shared state if the transaction confirms).

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

If the cookie is actually a reflection or reference to information held, for
this relationship, on the server, it's actually a stateful relationship with
paint on it.

BTP does recognise the scalability issues and the need to release
resources - a BTP participant can set a time-limit on how long it will wait
for the decision. It then inevitably risks the same problems as for THP,
mentioned above, but at least there was a warning.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

Received on Thursday, 30 May 2002 11:04:41 UTC