RE: Message reliability

AHA!!  In private conversation (off-list) I think we have gotten down to
it.  I really did NOT understand.  I think that you are objecting to the
phrase "error frequency" in the beginning of the explanation and
"performance" near the end.  Now all your comments make a lot more sense
to me.  (Sorry if it should have been clear to me and I missed
something).

Yes, I agree that these may not be the best choice of words, although as
covered in the conversation below one can make a case.  However, you
seem to be objecting to the more or less explicit introduction of a
timing factor, which does seem to me to be somewhat extraneous. Can you
suggest a better wording? 

Below is my attempt to word-smith this passage. 

>>> >The goal of message reliability is to both reduce the probability
of failure  
>>> >for messaging and to provide sufficient information about 
>>> >the
>>status of a
>>> >message delivery. Such information enables a participating agent to


...

>>> >It is important to note that a guarantee of the delivery
>of messages
>
>>> >alone, even if it were possible, would not necessarily guarantee
the overall reliability of a Web service due 
>>> >to the "end-to-end argument."[1]  It is only one component of this
overall reliability.  [Possibly add something here based on reliability
discussions in other sections, yet to come].

-----Original Message-----
From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com] 
Sent: Friday, October 24, 2003 2:36 PM
To: Cutler, Roger (RogerCutler); UCorda@SeeBeyond.com;
Hao.He@thomson.com.au; www-ws-arch@w3.org
Cc: Mike.Champion@SoftwareAG-USA.com
Subject: 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:57:36 UTC