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

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

Received on Wednesday, 28 August 2002 19:49:54 UTC