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

David,

I like your suggested tweak. Thanks!

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: [email protected]
phone: +1 508 234 3624

"Burdett, David" <[email protected]> wrote on 08/29/2002 
02:48:41 PM:

> Chris
> 
> >>>As you may recall, I was involved as well:) <<<
> 
> How could I forget ... ;)
> 
> I like your definitions,  however, they do not address what I think is 
the certainty that although
> you can be sure a message was received, you can never be absolutely sure 
that it was not.
> 
> So I would tweak "3" to say ...
> 
> "3.  the ability of both sender and receiver to carry out 1 & 2 with a 
high probability of success
> in the face of (inevitable, yet often unpredictable) network, system, 
and software failures"
> 
> What wording would you have in mind for "4"
> 
> David
> -----Original Message-----
> From: Christopher B Ferris [mailto:[email protected]]
> Sent: Thursday, August 29, 2002 4:32 AM
> To: [email protected]
> Subject: 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: [email protected]
> phone: +1 508 234 3624 
> 
> [email protected] 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:[email protected]]
> > Sent: Wednesday, August 28, 2002 11:33 AM
> > To: 'Geoff Arnold'; Cutler, Roger (RogerCutler)
> > Cc: [email protected]
> > 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:[email protected]] 
> > Sent: Wednesday, August 28, 2002 12:49 PM
> > To: Cutler, Roger (RogerCutler)
> > Cc: [email protected]
> > 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
> >