RE: Message reliability

In a quick read of this section it seems to deal with the tradeoffs on system 
performance when moving the comm failure retry to different layers of the 
architecture. There is some relationship to WS reliable messaging, but it 
depends on the reliability of the network and there are a number of factors 
to weigh in before one can claim that app level reliable messaging increases 
performance.

Hence this is not a simple claim one can make and unless you want to drag in 
the complexities of the issue, I suggest not stating that WS reliable messaging 
will increase performance.

Mike 


>-----Original Message-----
>From: ext Ugo Corda [mailto:UCorda@SeeBeyond.com]
>Sent: October 24, 2003 04:07 PM
>To: Mahan Michael (NRC/Boston); Hao.He@thomson.com.au;
>www-ws-arch@w3.org
>Cc: Mike.Champion@SoftwareAG-USA.com
>Subject: RE: Message reliability
>
>
>Mike,
>
>I think the term "performance" was taken from the article 
>referenced by Hao ( http://www.reed.com/Papers/EndtoEnd.html - 
>see the section "performance aspects").
>
>Ugo
>
>> -----Original Message-----
>> From: www-ws-arch-request@w3.org 
>[mailto:www-ws-arch-request@w3.org]On
>> Behalf Of michael.mahan@nokia.com
>> Sent: Friday, October 24, 2003 12:18 PM
>> To: Ugo Corda; Hao.He@thomson.com.au; www-ws-arch@w3.org
>> Cc: Mike.Champion@SoftwareAG-USA.com
>> Subject: RE: Message reliability
>> 
>> 
>> 
>> Ugo,
>> 
>> I understand better now. However, I think this is stretching the 
>> common understanding of performance. Perhaps qualifying the term 
>> to indicate this special use case. Something like 'failure 
>> performance' or 'recovery performance' but these both seem awkward 
>> and contradictory to me. Maybe, a short explanation of perf in 
>> this failure context would serve best. I would still object to 
>> the unqualified usage of performance here as this is not the 
>> typical system conditions one uses to measure it.
>> 
>> MikeM
>> 
>> >-----Original Message-----
>> >From: ext Ugo Corda [mailto:UCorda@SeeBeyond.com]
>> >Sent: October 24, 2003 02:17 PM
>> >To: Mahan Michael (NRC/Boston); Hao.He@thomson.com.au;
>> >www-ws-arch@w3.org
>> >Cc: Mike.Champion@SoftwareAG-USA.com
>> >Subject: RE: Message reliability
>> >
>> >
>> >Mike,
>> >
>> >The way I understand the performance part is by using an 
>> >example like the following.
>> >
>> >Suppose I submit a WS request and I know it will take the 
>> >service provider a maximum of three hours to satisfy the 
>> >request. At the end of the execution, the service provider is 
>> >supposed to return a response to me (either on the same 
>> >channel or as a call back).
>> >
>> >So, if there is no message reliability mechanism in place and 
>> >something goes wrong, all I can do is wait for three hours and 
>> >then realize that, since I did not receive a response within 
>> >that time, something must have gone wrong.
>> >
>> >But now suppose I have reliability in place, and that the 
>> >latency of the transport is three minutes. If I don't get an 
>> >acknowledgement within three minutes I know something went 
>> >wrong in the transport. So, in all those cases where something 
>> >goes wrong because of the transport, I can tell something is 
>> >wrong within 3 minutes and can take the appropriate measures 
>> >(e.g. resend) without wasting the whole 3 hours.
>> >
>> >In that respect, I think, it was said that a reliability 
>> >mechanism improves performance.
>> >
>> >Ugo 
>> >
>> >> -----Original Message-----
>> >> From: www-ws-arch-request@w3.org 
>> >[mailto:www-ws-arch-request@w3.org]On
>> >> Behalf Of michael.mahan@nokia.com
>> >> Sent: Friday, October 24, 2003 8:59 AM
>> >> To: Hao.He@thomson.com.au; www-ws-arch@w3.org
>> >> Cc: Mike.Champion@SoftwareAG-USA.com
>> >> Subject: RE: Message reliability
>> >> 
>> >> 
>> >> 
>> >> Two issues:
>> >> 
>> >> The definition states only that the messaging parties 
>involved are 
>> >> suitably informed and have the same understanding of 
>> >delivery status. 
>> >> The explanation then states that the goal is to reduce error 
>> >> frequency. It seems that this should be stricken - unless 
>it is in 
>> >> scope for reliable messaging to address compensating actions. (I 
>> >> don't know if that is true or not, but the definition doesn't say 
>> >> it).
>> >> 
>> >> Also, the explanation discusses overall system reliability which 
>> >> for me is tried to repeatable results. The explanation 
>then claims 
>> >> that performance is enhanced at both the message and system level 
>> >> when message reliability is applied. The way I measure 
>performance 
>> >> is by speed and latency metrics. In this dimension, reliable 
>> >> messaging 
>> >> does not enhance performance.
>> >> 
>> >> Mike
>> >> 
>> >> 
>> >> >-----Original Message-----
>> >> >From: www-ws-arch-request@w3.org 
>> >> [mailto:www-ws-arch-request@w3.org]On
>> >> >Behalf Of ext He, Hao
>> >> >Sent: October 23, 2003 06:14 PM
>> >> >To: 'www-ws-arch@w3.org '
>> >> >Cc: 'Champion, Mike'
>> >> >Subject: RE: Message reliability
>> >> >
>> >> >
>> >> >It was agreed to accept Roger's definition in today's 
>> >> >discussion, so the
>> >> >text has been modified to reflect the decision. 
>> >> >
>> >> >Editors of the architecture document, please incorporate the 
>> >> >text into the
>> >> >document.
>> >> >
>> >> >Hao
>> >> >
>> >> >
>> >> > 2.3.1.13 Message reliability
>> >> >2.3.1.13.1 Definition
>> >> >Message reliability is the degree of certainty that a 
>> >message will be
>> >> >delivered
>> >> >and that sender and recipient will both have the same 
>> >> understanding of
>> >> >the delivery status.
>> >> >
>> >> >... skip ...
>> >> >
>> >> >2.3.1.13.3 Explanation
>> >> >
>> >> >
>> >> >The goal of message reliability is to both reduce the error 
>> >> >frequency for
>> >> >messaging and to provide sufficient information about the 
>> >status of a
>> >> >message delivery. Such information enables a participating 
>> >> >agent to make
>> >> >a compensating decision when errors or less than desired 
>> >> results occur.
>> >> >High level correlation such "two-phase commit" is needed if 
>> >> >more than two
>> >> >agents are involved. Note that in a distributed system, it is 
>> >> >theoretically
>> >> >not possible to guarantee correct notification of delivery; 
>> >> however, in
>> >> >practice, simple techniques can greatly increase the overall 
>> >> confidence
>> >> >in the message delivery.
>> >> >
>> >> >It is important to note that a guarantee of the delivery of
>> >> >messages alone does not improve the overall reliability of a 
>> >> >Web service due
>> >> >to the "end-to-end argument."[1]  It may, however, improve the 
>> >> >performance
>> >> >of
>> >> >messaging, and therefore, the overall performance of a 
>> Web service.
>> >> >
>> >> >Message reliability may be realized with a combination of 
>> >> >message receipt
>> >> >acknowledgement and correlation. In the event that a message 
>> >> >has not been 
>> >> >properly received and acted upon, the sender may attempt a 
>> >> >resend, or some
>> >> >other compensating action at the application level.
>> >> >
>> >> >[1]http://www.reed.com/Papers/EndtoEnd.html
>> >> >
>> >> 
>> >> 
>> >
>> 
>> 
>

Received on Friday, 24 October 2003 16:32:24 UTC