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

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:42:58 UTC