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

RE: Message reliability

From: Jenkins, Wayne <jenkinsw@anz.com>
Date: Thu, 30 Oct 2003 11:38:40 +1100
Message-ID: <96EAF80F87559541A397A6C79EF6798202113D46@exgau100qsm00.oceania.corp.anz.com>
To: "He, Hao" <Hao.He@thomson.com.au>, <www-ws-arch@w3.org>
Cc: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>

Hi all,

I have been an avid reader of this thread and I would like to offer
a different opinion on the definition of "reliability".  My apologies
if this is not the appropriate forum.

A delivery service is reliable if it can satisfy delivery assurance 
constraints when delivering a message.

There are a number of different delivery assurance constraints that 
we could apply:  at-least-once, exactly once, ordered, at least once 
with 95% delivered within three seconds, 95% sent without error, acknowledgement, 
etc. It seems reasonable that commercial organizations will introduce 
a number of different types of assurance constraints according to their
terms of business.  If the definition of messaging reliability restricts 
the types of assurance constraints then its useful lifetime would seem 
to be limited.

On the performance front, we have had examples where the performance of
a system has improved by the introduction of different delivery assurance
constraints.  This improvement occured because we did not persist messages
on every hop but instead only persisted them on origination (for resending)
and at the destination (for duplicate detection).  This implementation
of "exactly once" assurance reduced cumulative residence
time (waiting + service time) by 40% because intermediate nodes did 
not need to persist messages.  This engineering tradeoff only results in
increased resending if any of the hops frequently fails to deliver 
messages.

Cheers,

Wayne.


-----Original Message-----
From: He, Hao [mailto:Hao.He@thomson.com.au]
Sent: Friday, 24 October 2003 8:14 AM
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 Wednesday, 29 October 2003 19:50:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:23 GMT