RE: Reliable Messaging Summary

FW: Reliable Messaging Summary
  Reliability:  A predictable quality of service. This is a separate issue
from fault tolerance, availability, or security.

  +1

  Reliable Messaging:  1) The ability: (a)of a sender of a message 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. (b)of the intended receiver of
the message to be assured that it receives and processes a given message
once and only once. of both sender and receiver of a message to carry out
(a) and (b) with a high probability of success in the face of inevitable,
yet often unpredictable, network, system, and software failures. 2) Common
Usage: An acknowledgement infrastructure between application and transport
layers intended to improve messaging reliability as described above.

  +1 with one change.

  The word 'whether' implies possibilities. It's not possible to know if the
message has not been received, but it's possible to determine that it has
been received (e.g. by receiving an ack). So I would suggest a minor
rephrase:

  "sender of a message to be able to determine that a given message has been
received by its intended receiver and to take compensating action if it
determined that the given message has not been received."

  I would also like to add two other point which I think should be covered
in the text to remove confusion.

  The term 'reliable messaging' is used to refer to a certain form of
messaging which is used to build reliable systems, but in itself is not a
solution for building reliable system. Whether we're talking about formal
models such as reaching concensus in face of failure, or about practical
implementations such as using coordination protocols and persistent queues:
these are all solutions for addressing reliability which tend to rely on
reliable messaging in one form or another.

  So my first suggestion is for the text addressing the issue of reliability
to indicate that solutions for addressing reliability (coordination,
persistence, etc) tend to rely on a messaing framework that provides
reliable messaging, and not suggest that RM is a solution for reliability.

  Reliable messaging can be addressed by various solutions depending on the
medium being used. If the communication is fully encapsulated in HTTP
request response, then the medium is IP and RM is actually addressed by TCP
(which has an ack infrastructure on top of TCP). If the communication is
encapsulated as a sequence of HTTP exchanges, then the medium is HTTP, and
RM is addressed by something on top of RM (WS-RM, or the recent specs
released by BEA, both address that).

  So my second suggestion is to somehow indicate that solutions are required
for different protocols, some of which are already available and others
which are being defined. Which solution is used depends on which protocol is
used, and solutions need to be offered for protocols which do not already
offer RM. For example, a synchronous request/response over a single HTTP
connection does not require any additional layer. BEA's specs give a good
example for a protocol built on top of HTTP which does require RM and
provide the minimal specification for addressing that. WS-RM also
illustrates such scenarios where WS-RM should be used.

  arkin



   Ac  knowledgement Infrastrucure - A set of rules defining how the parties
to a message should subsequently communicate with each other concerning the
receipt of that message and its validity.

  Message Validity: Three questions may be asked, in the order given below:
  1 - Was the message received the same as the one sent? Typically
determined by byte counts, check sums or other techniques that assure the
message is in the same as sent.

  2 - Does the message conform to the formats specified by the agreed upon
protocol for the message? typically determined by automatic systems against
syntax constraints (eg xml well formed) and structural constraints (validate
against one or more xml schemas or WSDL message definitions).

  3 - Does the message conform to the business rules expected by the
receiver? Additional constraints and validity checks performed by a business
process, typically checked by application logic and/or human process
managers.

  Thoughts on RM from Anne Thomas Manes:
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0425.html
  RM Breakout Notes:
http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jan/0085.html
  From Roger Cutler:
http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jan/0086.html
     and http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jan/0087.html
  From Dave Hollander:
http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jan/0088.html