RE: Reliable Messaging Summary

That's correct.  We believe in separation of concerns.  A wire protocol for
acknowledgements should not ALSO have a protocol for QOS.  That would be
separate.

Cheers,
Dave
> BEA's proposal includes a hint that the interacting parties can
> negotiate QOS out of bounds, but there's no mechanism
> proposed for doing
> this.
>
> --Jon
>
> >
> >>-----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:55:56 UTC