RE: Reliable Messaging Definition

Thanks Roger, this is really good example of a useful contribution to the
document and/or glossary ... clear rationale, direct quotes, references
cited, etc.  It could be a template for contributions by other people on
other topics [hint, hint],
 
Many analysts see the whole area of "reliable messaging" as one of the
things that the web services industry must sort out if it is to move
forward. If I recall correctly, it was considered one of the highest
priorities for this WG (along with security and choreography) in many of the
early discussions.  OASIS has started a WS Security TC, we've taken the
discussions of a Choreography WG about as far as they can go until the
question of venue is sorted out, 
so is it time to be thinking hard about whether we want to recommend
formation of a WG to pursue reliable messaging standards?
 
I belive that the REST camp thinks that this is unnecessary and that
reliability is an unavoidable duty of the application to ensure rather than
the infrastructure to provide.  I would hope that we can acknowledge this
position, draw the WSA reference architecture so that higher levels do not
NECESSARILY depend on a reliable messaging layer .. but not get sidetracked
by another discussion of whether or not a reliable messaging infrastructure
is a Good Thing or not.  Given the widespread interest in this subject, it
seems likely that we'll see one or more industry proposals for a reliable
messaging layer on top of SOAP (and/or HTTP??) before long, so we can't
ignore this.  That is, it is going to be shovelled onto our plate sooner or
later, so perhaps we should just be proactive and deal with it before it
becomes a crisis.  

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Monday, September 23, 2002 4:47 PM
To: www-ws-arch@w3.org
Subject: Reliable Messaging Definition



I believe that one of the actions that came out of the F2F as generally
desirable was to agree on a definition of reliable messaging.  There were
some threads on this subject a couple months ago, and I did not see a
consensus emerging at that time.  Following I document the "end points" I
can find from these threads, along with some personal comments in
[brackets].  I start with the definition that seemed to come closest to
generating consensus and work downward according to my personal perception
of how much consensus was achieved.  One overall comment:  None of these
definitions seem to recognize explicitly that the degree of certainty
achieved by reliable messaging is, in practice, a matter of balancing cost
and benefit.

Definition I - (Amalgamation of two) 
 <http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0283.html>
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0283.html 

 <http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html>
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html 

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 carry out 1 & 2 with a high
probability of success in the face of inevitable, yet often unpredictable,
network, system, and software failures.

[This one was the result of the longest thread and seemed to be the one
closest to having some consensus.  I personally think that it needs
restating to say positively what reliable messaging "is", not what it
"refers to", and at that point the choice of verbs is likely to be tricky in
order to avoid appearing to guarantee that which cannot be done.]

Definition I(a) - (Addition to Definition I) 
 <http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html>
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html 

4) The ability of a participating web services to coordinate and align their
transaction-related operations such that they can either commit or roll back
updates to their respective resources (e.g., application database and
transactional objects, persistent queues, etc.) used in the end-to-end web
service transaction. 

[I personally think that this issue is outside the scope of what people are
generally talking about when they use the term reliable messaging, and I am
not in favor of going in this direction.]

Definition II -
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0281.html>
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0281.html 

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

[I personally like this one, except that I'm not sure if 4 is possible to
guarantee and I would be happier if the verbiage was wordsmithed to make it
seem less like a sure thing that these things are going to happen every
time].

Definition III -
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0218.html>
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0218.html 

Reliable messaging is a protocol for sending and receiving messages over the
web which, if followed by all participants in the messaging, will reduce the
uncertainty of the message transmission to a practically acceptable level.
More specifically, if A sends a "reliable message" to B, who is not
necessarily expecting a message at a particular time, A may be assured that
the process will terminate (usually after a known time interval) in one of
three states.  The reliable messaging protocol attempts to maximize the
probability of the first state and minimize that of the third state.

State 1: The message has been received by B and a confirmation has been sent
back to A.  Both A and B agree that the message has been successfully
received.  (An elaboration of this is that B may send a confirmation message
back to A that the message has been received but that it was "damaged in
transit").

State 2: The message has not been received by B.  Both A and B agree that no
message has been successfully received. 

[This was my stab at a definition that started the threads.  I personally
like it because I understand it and I think it is reasonably accurate, but
it did not seem to gather a lot of support.]

Definition IV -
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0277.html>
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0277.html 

Here is a quote from the ebXML Message Service Specification v2.0 [1], p.
35: 
  "Reliable Messaging defines an interoperable protocol such that two 
   Message Service handlers (MSH) can reliably exchange messages, using 
   acknowledgement, retry and duplicate detection and elimination 
   mechanisms, resulting in the To Party receiving the message 
   Once-And-Only-Once.  The protocol is flexible, allowing for both 
   store-and-forward and end-to-end-messaging." 

[I personally feel that this definition is flawed because it seems to
promise something that probably cannot be done and certainly is not done by
the ebXML messaging spec.  The ebXML messaging spec does not guarantee that
the To Party will receive a message once and only once, and I believe that
it does not recognize adequately the possibility that Sender and Receiver
will disagree at the end of the process about whether the message has been
delivered.]