RE: Reliable Messaging Summary

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

In an input-only or input-output MEP, the consumer publishes the a service
definition. The consumer would then list the reliability requirement as part
of the service definition, indicating how it plans to use JMS (or any other
technology) on its side. This would also indicate to the produce what
requirements it has.

I definitely agree with you, putting that information inside the message
will not be very helpful. It has to be specified outside of the message
traffice.

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

JMS indeed has various level of guarantees that can be set by the API
depending, e.g. in consistency with the service definition. BEA's proposal
seem to mirror that, by combining different features depending on the
required level of guarantee. WS-RM at the moment only has the highest levels
of guarantee, but the spec does talk about having lower levels of guarantee.

Would it make sense to assign each level of guarantee some feature name, and
then list all these features in the service definition?

arkin

>
> --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:32:51 UTC