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

I also agree. I think that RM and BTP processing are complementary, and that
sometimes you might want to one, the other or both. Here are a few use
cases:

1. Two businesses want to exchange information between two existing legacy
systems.
In this case, the legacy systems may be incapable of carrying out a BTP
style recovery automatically. In this case the additional confidence
provided by RM which can be easily layered on top of the existing systems
provides a worthwhile benefit as it should significantly reduce the number
of errors that occur. When the inevitable happens and the process fails,
then manual methods can be used to recover the problem (i.e. people talking
on the phone followed by manual interactions with each system

2. On-line flight booking.
In this case, it is imperative that the flight is booked in real time as, if
the booking cannot be made immediately, then a booking will be made on
another airline. It is also important that the flight is not booked twice.
For this situation, doing BTP only might make sense since an immediate
response is required. Doing RM on top, might not make much difference.

3. Request for Quote.
In this case an initial request for a quotation is being sent to 20
suppliers, but a response is not expected for say, two days. This time you
might want to do both RM and BTP as RM would make sure that the original
quote got to its destination in a reasonably short timeframe, and BTP, could
be used to chase up the receiving of the response if it did not arrive in
time.

I'm not sure these examples are the best, but hope they are helpful.
Thoughts?

David

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Friday, December 20, 2002 9:31 AM
To: Assaf Arkin; Peter Furniss; Ricky Ho; www-ws-arch@w3.org
Subject: RE: Reliability is really two-phase (was RE: Reliable Web
Services)



I think that I agree with this.  By that, what I really mean is that I
think this correctly represents the requirements of the people in our
company who currently conduct business using EDI and who would consider
using web services only if they were assured of comparable security and
reliability.  I believe that they consider the messaging reliability
issues to be very important in themselves, independent of the business
conversation itself.

Once again, I want to reiterate how important I view these two issues to
be.  As far as core business processes go, there is just NO POINT in
messing around with any other features if these bases are not firmly
covered.  The people responsible for the business processes won't even
start talking with you to find out all the other wonderful things you
might offer.

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Friday, December 20, 2002 9:58 AM
To: Peter Furniss; Ricky Ho; www-ws-arch@w3.org
Subject: RE: Reliability is really two-phase (was RE: Reliable Web
Services)



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 17:41:41 UTC