RE: Message reliability

It is in Hao's email last night [1] which stated it reflected the teleconf 
decisions.

MikeM

[1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Oct/0067.html

>-----Original Message-----
>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>Behalf Of ext Cutler, Roger (RogerCutler)
>Sent: October 24, 2003 03:26 PM
>To: Mahan Michael (NRC/Boston); UCorda@SeeBeyond.com;
>Hao.He@thomson.com.au; www-ws-arch@w3.org
>Cc: Mike.Champion@SoftwareAG-USA.com
>Subject: 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:36:33 UTC