RE: Web services and CORBA

just briefly at various points:

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: 31 May 2002 04:50
> To: Peter Furniss
> Cc: www-ws-arch@w3.org
> Subject: Re: Web services and CORBA
>
>
>
> On Thu, May 30, 2002 at 04:03:53PM +0100, Peter Furniss wrote:
> > 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 would expect that 2PC is essential in the case where reaching or
> approaching ACID is required.  I would also expect that this would be
> the case where the parties involved have a pre-existing trusted
> relationship.
>
> But I'm personally more interested in the problem of how one coordinates
> any type of transaction between untrusted, uncoordinated parties.
> Hopefully that solution would be able to be used to approach hard core
> ACID style semantics, but I wouldn't count that a critical success
> factor.  Worst case, if this doesn't work out, then the previously
> coordinated parties can agree to use a different protocol as part of
> their previous coordination. 8-)

I believe you've actually summarised what BTP does there - making minimal
assumptions about
the prior relationship, it "coordinates ... uncoordinated parties". (don't
confuse btp's two-phase
with the typical lock-based mechanisms of deployed ACID)

> > > 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.
>
> Right.
>
> > 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.
>
> Aside; "stateful" in this case seems to imply a stateful service, rather
> than a stateful interaction with a service.  FWIW, I was earlier talking
> about the latter, not the former.

This is what I meant about spirit and letter. When it comes to the crunch,
where fields and identifiers are carried in the total message is irrelevant.
If both sides, regardless of layer, are holding state that links
specifically to the state held by the other, it's stateful in the sense that
REST seeks to avoid. And you cannot avoid that if you want to get
coordination.

Lack of prior trust or coordination means that the parties need to be able
to put bounds on their exposure (e.g. timelimits on pending period).

> > 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).
>
> Right.
>
> > > (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.
>
> Right.  I think I said that.
>
> > 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.
>
> THP still allows for consistency, because you do receive unambiguous
> information as to whether the lock was held or not.  The problem is
> obviously that the probability of not having the hold when you thought
> you did, is not insignificant.  That's why I don't think THP is
> sufficient as a general solution.

BTP (committee spec 1.0 will be released on Monday) supersets THP in this
area. Breaking promises (releasing the hold) is allowed, but BTP will make
sure this is known.  But the need to break promises derives from the
fundamental business requirement that as the promise concerns resources that
are owned by an autonmous organisation.

> I suggest we take this offline, or to another archived forum.  If we
> come to any conclusion, we can report back.

There's a lot in the BTP documents (including the Primer which will come out
on Monday as well).  But this thread has been more about whether REST
principles (as opposed to details about use of HTTP) can support open
coordination and consistency. I don't believe they can.

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 Friday, 31 May 2002 04:48:26 UTC