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

RE: Reliability is really two-phase (was RE: Reliable Web Services)

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 20 Dec 2002 07:58:06 -0800
To: "Peter Furniss" <peter.furniss@choreology.com>, "Ricky Ho" <riho@cisco.com>, <www-ws-arch@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNIEEMCPAA.arkin@intalio.com>

I'm trying to draw a parallel to the business world.

When I engage in a business relationship with a partner I do a lot of back
and form communication, sign contracts, etc to ensure our engagement will
succeed. In effect we and my partner are coordinating. In the WS world I
could achieve the same thing by exchanging messages back and forth, and I
can further standardize the semantics that are common to all interactions
using a standardized protocol. BTP would be an example for such a protocol,
WS-Tx would be another.

I can do my communication in a variety of ways, like talking on the phone,
sending a fax, sending a FedEx. Actually, I can send it postal, much
cheaper. But FedEx gives me a certain level of guarantee regarding timing,
retry and tracking. Think of RM as being the FedEx when a Web service
resorts to using an asynchronous package delivery option, and without RM you
get the same (not bad, just not good enough) guarantee as the postal
service.

I don't rely on FedEx to get my business relationship working, I use other
forms of coordination. But I don't rely on coordination to make sure my
signed contract gets to the lawyer in time, I use FedEx. In my opinion that
analogy carries well into the WS world. BTP and RM are orthogonal to each
other, they are not alterantive. In fact, they are complementary. You would
want to use both, you would send transaction contexts in your messages (and
acks), because you are exchanging messages inside transactions. And you
would want to use RM because it provides faster delivery (resend), something
that BTP doesn't do for you.

arkin

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Peter Furniss
> Sent: Friday, December 20, 2002 3:56 AM
> To: Ricky Ho; www-ws-arch@w3.org
> Subject: RE: Reliability is really two-phase (was RE: Reliable Web
> Services)
>
>
>
> Ricky Ho replied to me:
>
> > Are you implying at point (j) that by using BTP, reliable
> > messaging is not
> > necessary ?  I think they are solving orthogonal problem.  In fact, BTP
> > without reliable messaging is not sufficient for conducting high money
> > value transaction in a reliable manner.
>
> Yes, I don't think RM is necessary with BTP. The BTP exchange means that
> the application work (e.g. money transfer) won't happen unless both sides
> agree that they understand and want to do it. If the pattern follows the
> typical sequence:
>
> 	client requests transfer
> 	server says it can do it, iff the client confirms
> 	client confirms
> 	server applies confirmation, and tells the client it is done
>
> then you have a stronger mechanism than RM, which is concerned only
> with being a reliable postman.  (admittedly, if you map things in a
> particular way, the two end up becoming fairly close - certainly if the
> detailed application behaviour is fixed assuming an RM pattern, BTP
> can carry the identical semantics - though it has some extra
> flexibilities that RM would have difficulty with).
>
> Peter
>
>
> >
> > Rgds, Ricky
> >
> >
> > At 02:16 AM 12/18/2002 +0000, Peter Furniss wrote:
> >
> >
> > >The reliability requirement really means that you need
> > >the sort of mechanisms and exchanges of two-phase outcome
> > >(as in OASIS BTP).  "reliable messaging", depending on the
> > >details of its mechanisms, is variously giving less that it
> > >seems, or is just as complicated (and, in some cases, both).
> > >
> > >
> > >To expand that assertion a bit:
> > >
> > >a) i'm assuming reliability can be defined as two parties
> needing to have
> > >a consistent view as to whether some work has or has not been done
> > >by one of them at the request of the other
> > >   [ this is the 0 or 1 case, and is the centre of state alignment -
> > >   where I change my view of the shared state because I know you
> > have/will]
> > >
> > >
> > >b) the critical feature is that one side accepts
> > >that the other side will make the definitive determination as
> > >to whether the work is to be done; the deferring side
> > >agrees to accept/apply/follow that determination once it knows of it
> > >
> > >  [ which is the essence of the solution to the two armies
> > problem - their
> > >problem was that neither side will make an unconditional decision, but
> > >wants the other side to make an irrevocable decision as a condition of
> > >its own]
> > >
> > >c) once the determination has been made, the repetition and recovery
> > >rules of the transaction protocol make sure the other side will
> > >know eventually
> > >
> > >d) you normally want to know that the application has really done
> > >the work. In some cases, it may be sufficient to know that
> > >the work will eventually be done (e.g. it's been dropped on a
> > >reliable queue) - but that means that either there is no
> > >comeback or any comeback is a whole new activity.
> > >
> > >e) the "simple" ack approach actually requires some extra
> > >messages to avoid one or both sides having to remember the
> > >request (or some identification on it) indefinitely or have
> > >a complicated set of timeout rules as to when they can forget
> > >things. (and that's before we worry about surviving crashes)
> > >
> > >f) reliable messaging (including things like HTTPR) are
> > >distinguished from two-phase outcome only by what is counted
> > >as the "decision" - it's "message received", not "work is/will
> be done".
> > >The systems have to store similar information/identifiers
> > >and follow similar rules as to when to persist and
> > >delete this information. [ in other words, it's not really simpler
> > >to just use reliable messaging ]
> > >
> > >g) some of the scenarios differ from the classic
> > >two-phase commit exchanges in that the sender of the first
> > >message is the one that defers to the other side's decision.
> > >(classic two-phase is client asks server to defer to the
> > >client's decision). This has some impact on how the
> > >relationship gets established, but doesn't significantly
> > >affect what happens later (in terms of retries, persistence,
> > >recovery sequences).
> > >
> > >h) expel from your mind any assumptions about how the party
> > >that is waiting on the other's determination/decision is
> > >holding itself able to obey. (two-phase commit does *not*
> > >imply two-phase locking). It may hold the information in
> > >a distinguished interim state (outbound buffer, uncleared funds,
> > >marked as reserved). It may completely perform its work and
> > >retain a means of un-performing it. It may just check it could
> > >perform its work and remember what it must do.
> > >
> > >i) the transaction mechanisms actually allow for more complex
> > >arrangements - the coordination role can be distinguished from
> > >the resource-holding parties on each side, and there can be
> > >more than two such parties. But for comparison with reliable
> > >messaging, we can consider all the roles to be on one side or
> > >the other, and consider only a single bilateral relationship.
> > >
> > >j) using a loosely-coupled transaction mechanism like BTP means
> > >the application code doesn't have to get tangled up in the recovery,
> > >repeats etc. Setting of timeouts and the like becomes a
> > >configuration question (possibly even a dynamic configuration
> > >question if you really want to).
> > >
> > >k) a two-phase outcome exchange doesn't really seem to count as
> > >"orchestration" or "choreography" as I understand those. It's
> > >just a matter "please do this", "I can do this", "I can't do this" etc.
> > >Any compensation/counter-operation/reversal is delegated to the
> > >party that has to do the reversal, rather than having to be
> > >explicitly exposed as a counter-operation distinctly accessed
> > >by the other side.
> > >
> > >
> > >That's enough for now - I'm probably still obscure through
> > >brevity, but the message is long enough already.
> > >
> > >Peter
> > >
> > >------------------------------------------
> > >Peter Furniss
> > >Chief Scientist, Choreology Ltd
> > >
> > >    Cohesions 1.0 (TM)
> > >    Business transaction management software for application
> coordination
> > >
> > >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, 20 December 2002 10:59:36 GMT

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