W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

RE: Champions for Draft-status requirements? / D-AC017

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 29 Aug 2002 07:32:02 -0400
To: www-ws-arch@w3.org
Message-ID: <OFBF5600E6.F7DCB7B3-ON85256C24.000C1297-85256C24.003F44BD@rchland.ibm.com>

As you may recall, I was involved as well:) I think your characterization 
is close. 
I offer yet another stab at a definition as I believe that your definition 
is slightly suggestive
of a solution:

Reliable messaging refers to:
1)  the ability of a sender to be able to determine whether a given 
message has been 
received by its intended receiver and to take compensating action in the 
event a given message 
has been determined not to have been received
2) the ability of the intended receiver to be assured that it receives and 
processes a given message
once and only once
3) the ability of both sender and receiver to successfully carry out 1 & 2 
in the face 
of (inevitable, yet often unpredictable) network, system, and software 

As Geoff has pointed out, there may be varying QoS characteristics that 
apply mostly to
the degree to which sender and receiver will provide for 3 to minimize the 
potential for
undelivered messages or for compensation of catastrophic failure.

There is, I believe, also a 4th characteristic of reliable messaging; the 
ability of
an application to include the act of sending and receiving a message in 
transactions with other resource managers such as the application's 
database. I suppose 
that this could technically be considered an aspect of 3, but an important 
point worthy of


Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 08/28/2002 07:49:55 PM:

> I was involved in ebXML Messaging from the early days, so how about this 
> a statement of the requirement from an ebXML perspective ...
> Reliable Messaging is the ability for one service to use a protocol to 
> a message to another so that:
> 1. The sender of the message is provided with positive confirmation that 
> message was successfully delivered
> 2. The probability of successful delivery of the message is very high
> 3. The recipient of the message can identify and, if required, ignore 
> duplicates of the message
> 4. The sender of the message is notified if, for some reason, delivery 
> the message was not possible or is uncertain
> Hope this helps.
> David
> -----Original Message-----
> From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
> Sent: Wednesday, August 28, 2002 11:33 AM
> To: 'Geoff Arnold'; Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: RE: Champions for Draft-status requirements? / D-AC017
> OK by me.  I was just giving it a shot, for what it was worth.  Perhaps 
> could flesh out a better explanation of what reliable messaging is?  As 
> keep saying, I think it is important because there is a very widespread
> perception that security and reliable messaging are the hot spots for 
> web services practically usable for business processes.  The 
> doc talks a lot about security ...
> -----Original Message-----
> From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM] 
> Sent: Wednesday, August 28, 2002 12:49 PM
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: Re: Champions for Draft-status requirements? / D-AC017
> On Wednesday, August 28, 2002, at 01:06  PM, Cutler, Roger 
> (RogerCutler) wrote:
> >  One of the solutions to this problem, I think, is to
> > define reliable messaging a bit more accurately, for example by
> > replacing
> > terms like "reliably exchange" (below) with something like "reduce the
> > uncertainty of the message transmission to a practically acceptable 
> > level".
> The phrase "practically acceptable level" seems to be inviting trouble. 
> not simply talk about measurable reliability levels (i.e. QoS)?
> Curious,
> Geoff
Received on Thursday, 29 August 2002 07:32:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:58 UTC