Re: Proposed text on reliable messaging

There is a massive difference between knowing that a message has been 
delivered and knowing whether the business function that should be 
triggered by that message has been performed. The former is part of 
reliable messaging, the latter is not.

On Monday, August 25, 2003, at 07:52  AM, He, Hao wrote:

> I would argue that "got through" is just as vague as "acting on the
> message".  What matters to end applications is that they need to know
> whether messages they sent have caused the expected effects so they 
> can take
> corresponding actions.  Simplying knowing that a message has been 
> shipped is
> not sufficient. A message is shpped from point A to point B does not 
> mean
> much unless the intented receiver at point B can act on the message. 
> This is
> the end-to-end argument in http://www.reed.com/Papers/EndtoEnd.html
> The point is that millions of things can still go wrong even your 
> messages
> arrive at point B.
>
> Hao
>
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Saturday, August 23, 2003 10:33 PM
> To: He, Hao
> Cc: www-ws-arch@w3.org; 'w3c-wsa-editors@w3.org'
> Subject: Re: Proposed text on reliable messaging
>
>
>
> I have serious doubts about some of this stuff.
>
> The requirement to `act on a message' is vague, onerous and off the
> point. If the intent is to encourage reliability then this neither
> guarantees nor is sufficient for the goal.
>
> Clearly, the essence of reliable messaging is that the *sender* of a
> message has some guarantee that the message *got through*. That should
> be the focus of this topic, not *acting on the message*
>
> Frank
>
> On Thursday, August 21, 2003, at 08:28  AM, He, Hao wrote:
>
>> I've taken my action item to work on the reliable messaging text. I've
>> tried
>> to improve the text on the following aspects:
>>
>> 1. To clarify the concept of "reliable messaging" under the context of
>> Web
>> services.
>> 2. To articulate more on the difference between "guarantee of
>> delivery" and
>> "reliable messaging"
>> 3. To add the "end-to-end argument".
>> 4. To explain why the "life cycle" of a message may be important to
>> improve
>> reliability.
>> 5. To correct a few typos.
>>
>> As always, your comments are appreciated.
>>
>> Hao
>>
>> 2.3.1.13 Reliable messaging
>> 2.3.1.13.1 Definition
>>
>> Reliable messaging is a feature that may contribute to the overall
>> reliability and efficiency of Web services. Reliable messaging 
>> requires
>> participating software agents to act on a message after receiving it.
>>
>> Relationships to other elements
>>
>> reliable messaging is
>>
>> a feature
>>
>> reliable messaging may be realized by
>> a combination of message acknowledgement and correlation.
>>
>> a good practise of reliable messaging is
>> to make the life cycles of messages available to participating 
>> software
>> agents.
>>
>> 2.3.1.13.3 Explanation
>>
>> Reliable messaging can improve the overall reliability and efficiency
>> of Web
>> services. Reliable messaging in Web services not only requires the
>> delivery
>> of messages but also the contact on the receiving agent to act on 
>> those
>> messages as defined in service contracts.
>>
>> The goal of reliable messaging is to both reduce the error frequency
>> for
>> messaging and to provide sufficient information about the life cycle 
>> of
>> messages. Such information enables a participating agent to make a
>> compensating decision when errors or less than desired results occur.
>> It is
>> important to note that a guarantee of the delivery of message  alone
>> does
>> not improve the overall reliability due to the "end-to-end
>> argument."[1]  It may, however, improve the performance of messaging.
>> Requiring an agent to act on a message after receiving it would
>> improve the
>> overall  reliability of Web services that only involve two software
>> agents.
>> High level correlation such "two-phase commit" is needed if more than
>> two
>> agents are involved.
>>
>> Reliable messaging may be realized with a combination of message
>> receipt
>> acknowledgement and correlation. In the event that a message has not
>> been
>> properly received and acted upon, the sender may attempt a resend, or
>> some
>> other compensating action at the application level. Note that in a
>> distributed system, it theoretically
>> not possible to guarantee correct notification of delivery; however, 
>> in
>> practice, simple techniques can greatly increase the overall
>> confidence in
>> the message delivery.  For example, a good practise is to make
>> messaging
>> idempotent so a sender can attempt sending a message again without
>> worrying
>> of causing undesired effects, if it is unsure about the status of the
>> previous message.
>>
>> Message correlation may be used by the receivers of messages to ensure
>> that
>> messages are only acted on once - with duplicate messages being
>> ignored or
>> treated as errors. Whether two messages are duplicated is defined at
>> the
>> application level.
>>
>> [1]http://www.reed.com/Papers/EndtoEnd.html
>> <InterScan_Disclaimer.txt>
> <InterScan_Disclaimer.txt>

Received on Sunday, 24 August 2003 22:21:43 UTC