RE: Reliable Messaging Summary

> -----Original Message-----
> From: Jon Dart [mailto:jdart@tibco.com]
> Sent: Wednesday, March 05, 2003 12:51 PM
> To: Assaf Arkin
> Cc: Cutler Roger (RogerCutler); www-ws-arch@w3.org
> Subject: 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.

Can we say that the JMS API should be used with some JMS provider in a
manner that is required to support the protocol?

For example, if the communication requires durability at the consumer side,
then this would be expressed in generic terms (protocol/API independent) but
the implementation using JMS would have to use the API by setting specific
fields, e.g. creating or using a durable queue?

arkin

> 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 17:12:01 UTC