W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2003

RE: Message reliability

From: <michael.mahan@nokia.com>
Date: Fri, 24 Oct 2003 13:50:17 -0400
Message-ID: <5C76D29CD0FA3143896D08BB1743296A023403AA@bsebe001.americas.nokia.com>
To: <RogerCutler@chevrontexaco.com>, <Hao.He@thomson.com.au>, <www-ws-arch@w3.org>
Cc: <Mike.Champion@SoftwareAG-USA.com>

No - my phone was cutting out during the teleconf when reliability was
discussed. If the group addressed this specifically and an agreement was 
made then I apologize for bringing it up again. I assume this was discussed 
on the teleconf - the latest text from you does address the issue I am 


>-----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 12:48 PM
>To: Mahan Michael (NRC/Boston); Hao.He@thomson.com.au;
>Cc: Mike.Champion@SoftwareAG-USA.com
>Subject: RE: Message reliability
>Are you aware of the objections I had to the definition that strikes
>what you want striken?  How do you answer that?
>-----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 10: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 
>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.
>>-----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
>> Message reliability
>> 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 ...
>> 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 
>>not possible to guarantee correct notification of delivery; 
>however, in
>>practice, simple techniques can greatly increase the overall 
>>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 
>>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.
Received on Friday, 24 October 2003 13:50:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:09 UTC