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

David,

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 
failures

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 
coordinated 
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
mention.

Cheers,

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 
as
> a statement of the requirement from an ebXML perspective ...
> 
> Reliable Messaging is the ability for one service to use a protocol to 
send
> a message to another so that:
> 1. The sender of the message is provided with positive confirmation that 
the
> 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 
any
> duplicates of the message
> 4. The sender of the message is notified if, for some reason, delivery 
of
> 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 
you
> could flesh out a better explanation of what reliable messaging is?  As 
I
> keep saying, I think it is important because there is a very widespread
> perception that security and reliable messaging are the hot spots for 
making
> web services practically usable for business processes.  The 
requirements
> 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. 
Why
> not simply talk about measurable reliability levels (i.e. QoS)?
> 
> Curious,
> 
> Geoff
>