Re: Reliable Messaging Summary

I'd like to point out that a truly asynchronous protocol, such as JMS, 
doesn't easily fit into the web service reliability models I've seen so 
far. JMS producers and consumers are decoupled. Message persistence is 
under control of the producer. "Durability" -- the ability to receive 
messages that have arrived while disconnected -- is a consumer-side 
option. Duplicate detection is also a feature you turn on or off at the 
consumer end. Acknowledgement is yet another option. Neither end can 
dictate the full spectrum of reliability options for the interaction.
Exactly which flavor and degree of reliabiliy you get depends on the 
combination of options selected.

You can design a protocol that enables end to end reliability, in some 
sense, using an inherently unreliable transport. IMO this effort should 
also be able to map to an inherently reliable transport if such is 
available. But those transports have restrictions and peculiarities that 
then need to be respected: otherwise the binding will not work. I am 
concerned that the modelling to date has been a bit too HTTP-centric.

--Jon

Assaf Arkin wrote:
>  
> 
>     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_
> 
> 
> 
> 
>

Received on Wednesday, 5 March 2003 15:53:40 UTC