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:12:44 UTC