FW: Reliable Messaging Summary

Mike suggested that I send this to the public list as a contribution to
possible RM wording in the WSA doc that might be discussed at the F2F.
I have edited out some personal comments ...

>  -----Original Message-----
> From: 	Cutler, Roger (RogerCutler)  
> Sent:	Monday, March 03, 2003 4:03 PM
> To:	'dmh@contivo.com'
> Cc:	'Champion, Mike'; 'Hugo Haas'
> Subject:	Reliable Messaging Summary
> 
> Mike ... suggested that I try ... [to summarize the RM threads].  I
> looked at the sources below -- and the muse would not come.  That is,
> I could not think of anything to say that was not essentially what I
> said before, which wouldn't be very useful.  It seems to me that where
> we were going -- putting a hierarchy of definitions into the Glossary
> of "reliability", "reliable messaging", "acknowledgement
> infrastructure" and "message validity" has merit, and the definitions
> you [Dave Hollander] reworked seem fine to me (that's the last
> reference).  Anne's comments includes a definition of reliability (I
> think in the context of messaging) from WS-RM that looks useful and
> some correct comments about the domain of applicability of WS-RM.
> 
> One other thing -- looked briefly at the RM submission from BEA that
> was released very recently.  At a quick look I'd say it covers much
> the same ground as WS-RM -- if there are any substantially new
> functions or twists I missed them -- but their explication of the
> function of RM is far, far better than in WS-RM.  You will recall that
> I complained about the lack of such analysis in WS-RM.
> 
> Here are suggested definitions.  I am cc-ing Hugo, Mr. Glossary.  It
> is my opinion that it would be fairly safe and useful to put at least
> the expanded (second) definition of RM and that of Ack Infrastructure
> into the Glossary.  
> Reliability:  A predictable quality of service. This is a separate
> issue from fault tolerance, availability, or security.
> 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.
> Acknowledgement 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
> 
> 
> 
> 
>