Re: Reliable Messaging Summary

Assaf Arkin wrote:

> 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?

The independent decision making power of consumer and producer, and (in 
JMS) the scoping of some options at the session level, have some 
implications, one of them being that you need to specify reliabiilty 
options for the consumer outside of the message traffic itself (e.g. it 
couldn't be set by the sender in the first message it originates).

If this is granted, then one question is whether you want a restrictive 
version of reliability only (e.g. once and only once semantics) or you 
want to be able to model the other kinds of reliability allowed by JMS 
(and other systems). If the former, you can say that JMS in this context 
will use certain options and others aren't allowed.

--Jon

> 
> 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:18:24 UTC