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:02:31 UTC