RE: Proposed text on reliable messaging

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>