RE: Reliable Messaging - Summary of Threads

The reference below to
http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0075.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0075.html>
does not, for some reason, display gracefully on my browser.  If you
have the same problem, you might try
http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0070.html
instead.
-----Original Message-----
From: Cutler, Roger (RogerCutler) 
Sent: Friday, December 13, 2002 11:48 AM
To: www-ws-arch@w3.org
Subject: Reliable Messaging - Summary of Threads



I somewhat foolishly took on an action item of summarizing the threads
on Reliable Messaging.  Since then the threads have exploded even
further, and I'm afraid I am not going to do this justice.  However, let
me do my best.  First I will summarize the trends I see, second I will
make a recommendation, third I will list a (very) few references to
messages in these threads.  These references are NOT comprehensive, and
I apologize to all whose valuable contributions I have left out.  Also
apologies if I get some of the terminology or concepts wrong.  If you
think I've messed up, please try to help fix it.

Summary of Trends: 
---------------------------- 
I have been getting the following out of the reliable messaging threads:


1 - There seem to be quite a few people that think there is a lot of
value to a simple acknowledgment mechanism.  Although it has not been
discussed much, it seems to me that we want to find out if this is the
kind of "lightweight" issue that the XMLP WG would consider accepting.

2 - There are a number of people who are essentially saying, "Look at
the ebXML reliable messaging spec".  See if it is what one needs, close
to what one needs, or a reasonable basis for starting off toward what
one needs.  That is, as a model for the "ack" mechanism.

3 - There is concern about the "two army" problem, which essentially
says that it is not possible, given certain assumptions about the types
of interactions, for all parties in the communication to reliably reach
consensus about what has happened.  I have been trying to encourage the
objective of documenting the scenarios that can come up in and their
relative importance and possibly mitigating factors or strategies.  I
haven't seen people violently disagreeing but I wouldn't call this a
consensus point of view.  I consider the ebXML spec as weak in
discussing the two-army problem.

4 - A number of people seem to feel that there are higher levels of the
reliability question that are more properly addressed on the
choreography level.  Whether this ends up as part of the business
agreements themselves or the choreography mechanism is unclear to me,
but at least it would seem useful for a choreography WG to explore this
issue somehow.

5 - There has been discussion the overall reliability of messaging that
involves intermediaries.  It is not clear to me whether this belongs in
the "simple ack" bucket or the choreography bucket, but I kind of
suspect the latter.  There are MANY, MANY important business
applications that involve simple A<->B communication.

6 - Every time the reliable messaging issue comes up at least one person
tries to classify it as a Quality of Service issue and to lump it in
with a whole bunch of other QoS issues.  I personally think that
reliable messaging, along with security, are the two primary barriers to
business adoption of web techniques for core business practices, and as
such does not deserve to be buried in that way.

In addition, there has been some discussion that I cannot accurately
characterize about whether reliable messaging belongs on the wireline
level (as in HTTPR) or on the messaging level (as in an ack in XMLP)
plus the choreography level (as in business agreements).  There have
been some phrases used that I am avoiding because they seem to me to
bleed over into other arguments.  However, for a variety of reasons most
people seem to agree that the issue belongs on the messaging (or perhaps
"application") and choreography level.

Recommendation 
------------------ 
I recommend that we draft a request to the XMLP WG to consider the "ack"
scenario of reliable messaging, as discussed in these threads.  I think
that this request should contain some verbiage about the importance that
we think RM has in removing barriers to adoption by businesses of web
techniques and a strong recommendation that they look carefully at the
ebXML spec, with the idea that this might be a good starting point or
even might be the answer as it stands.  I also think that we should
suggest to them that there is a simple, high-value issue that can be
addressed usefully without solving the more complex problems.

References 
----------- 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0093.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0093.html>  -
Using both synchronous and asynchronous messaging 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html>  -
Multiple hops and intermediaries 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html>  -
Intermediaries and speed of transport 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0082.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0082.html>  -
Reference to ebXML spec 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0075.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0075.html>  -
Failure scenarios, simple enhancements and relationship to choreography

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0083.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0083.html>  -
Multiple levels of reliable messaging 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0056.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0056.html>  -
Two army problem 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0053.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0053.html>  -
Simple "ack" defined.