RE: Message reliability

I'm sorry, I really don't understand this conversation.  The word
"performance" does not occur either in the original definition, which I
objected to on grounds already documented, nor in the suggested
alternative, which was accepted in the concall.  Where did this come
from?

-----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 2:18 PM
To: UCorda@SeeBeyond.com; 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 15:26:48 UTC