RE: Reliable Messaging Summary

> -----Original Message-----
> From: Jon Dart [mailto:jdart@tibco.com]
> Sent: Wednesday, March 05, 2003 2:40 PM
> To: Assaf Arkin
> Cc: Cutler Roger (RogerCutler); www-ws-arch@w3.org
> Subject: Re: Reliable Messaging Summary
>
>
> Assaf Arkin wrote:
> > Would it make sense to assign each level of guarantee some
> feature name, and
> > then list all these features in the service definition?
>
> It would make sense, but the difficulty is finding a common feature set
> for reliable messaging systems, plus the difficulty that some messaging
> systems may not allow a specific combination of features. The challenge
> is to find an abstract description that you can map to actual
> capabilities. (The possible introduction of intermediaries, implying a
> hop across protocols, introduces other problems).

Sounds like an idea for a task force ;-)

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

I would be interested in using WS-Policy or a similar framework to express
such assertion. I think BEA's proposal goes a long way to identify what
assersions are required and how they could be composed to express the proper
QoS.

arkin

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