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 14:16:48 UTC