RE: Message Expiry

Comments embedded.


>What it does do, is increase the confidence of the sender that the message 
>was not delivered and/or was not processed as:

<Ricky>
When it comes to reliability, we are talking about "absolute" things, so 
I'm not sure how a "degree of confidence" will help here.
 From an RM perspective, there are three "absolute" state
a) "delivered" -- The RM is sure about the message is delivered one and 
only once
b) "undelivered" -- The RM is sure about the message has not reach the 
destination
c) "in-doubt" -- The RM is unsure, so it pass that to the Application level.

Note that the "in-doubt" state is different from "degree of confidence".
In the former case, the RM is NOT drawing any conclusion and pass that on 
the application who deals with that.
In the latter case, the RM is using its own judgement (based on its degree 
of confidence) to make a conclusion for the application.  (In other words, 
the application sees the status "undelivered" but NOT "in-doubt").  I 
consider this is inappropriate because "in-doubt" situation has to be 
resolved within the application context.
</Ricky>


>1. No acks were received even after repeated sending of the message - 
>suggesting that the destination is not accepting messages

<Ricky>
Yes.  But "the destination is not currently accepting message" is very 
different from "the destination hasn't ever accepted the message".  It is 
possible that the receiver received and persisted the message, then crash 
before it send the ACK.
The only conclusion can be drawn is there is a permanent problem (maybe the 
network or the receive site) rather than a transient one.
</Ricky>


>2. If the message has time expired, then, even the destination received 
>the message, the sender can be certain that it would not be processed.

<Ricky>
I don't see how the sender can be certain about this.  Think about this 
scenario
1) Sender RM send the message
2) Receiver RM receive the message and persisted before the expiry time.
3) The network between the sender and receiver got disconnected
4) The receiver RM send back the ACK (of course, it never get to the sender RM)
5) The receiver app process the message
6) The sender RM keep resending the message (of course, all lost)
7) Now it is at the expiry time, the sender gives up its retry

Is it appropriate for the sender to consider the message would not be 
processed after step 7 ?
</Ricky>


>This leaves the edge case where:
>1. The first message was received and processed successfully, but
>2. No ack could be successfully delivered, e.g. because the destination 
>failed
>
>This why in my description of levels of reliable messaging, there are 
>levels above level 1.
>
>David
>PS BTW, you completely missed the point of my original email
>
>-----Original Message-----
>From: Ricky Ho [<mailto:riho@cisco.com>mailto:riho@cisco.com]
>Sent: Sunday, December 15, 2002 11:03 PM
>To: Burdett, David; www-ws-arch@w3.org
>Subject: Re: Message Expiry & the WS Architecture
>
>I'm seeing the following value that "expiry time" has brought to the table
>
>1) For the sender to communicate application level semantics
>=============================================
>The sender want to tell the receiver not to waste any processing effort
>after certain time because the result is not useful anymore. (e.g. "The
>purchase order request is no longer valid if you receive it after 5 PM
>today because that is too late for me").  This courtesy notification is
>purely for optimization at the receiver side (it is OK that the sender
>doesn't do that and silently drop the message which passed the expiry time,
>this just waste the receiver's effort).  I don't think this expiry time has
>any effect in improving the message delivery reliability.  The value
>setting of the expiry time is purely on business conditions but not the
>network transport latency.
>
>2) For the sender to set a deadline for its retry effort
>======================================
>If the receiver still hasn't get the message after the expiry time, there
>is no point for the sender to resend the message.  However, this doesn't
>mean the sender can make a conclusion that the message hasn't been
>received.  The sender just know resending further is useless, but he still
>need to use another mechanism to resolve the "in-doubt" status (such as
>sending a query message).
>
>However, the sender CANNOT draw a conclusion that the message is
>undelivered if he get back no ACK after the time expiry.  In other words,
>the time expiry has NO effect to improve the reliability of message delivery.
>
>At 11:51 AM 12/15/2002 -0800, Burdett, David wrote:
>
> >I want to start a new thread on an Architectural issue and use the idea of
> >Message Expiry to illustrate it. Note that I could just as easily have used
> >other concepts as it is the principle that I want to bring out.
> >
> >Recently there has been a lot of discussion on Reliable Messaging. One of
> >the ideas in LEVEL 1 of Reliable Messaging that I described, was the idea
> >that a message expired and should not be processed after a certain point in
> >time.
> >
> >Now the obivous way to identify when a message expires is to include an
> >"ExiresAt" header in a SOAP Feature/Module in a message that contains the
> >time after which the message must not be processed - this is what ebXML
> >Messaging did with its TimeToLive header.
> >
> >Now for some questions ...
> >QUESTION 1. Is the idea of Message Expiry **exclusive** to Reliable
> >Messaging?
> >If the answer is yes, then you can easily include how Message Expiry works
> >in the RM spec. But I don't think so this is likely. I can quite imagine
> >sending a message that has an expiry time, but not care if the message was
> >delivered. So there is another question ...
> >
> >QUESTION 2.  If the definition of Message Expiry is not in the RM spec, 
> then
> >where should it be defined and who should define it?
> >You *might* argue that some very basic headers like MesssageId goes in the
> >XMLP spec to support some of the ideas that Assaf has been putting forward,
> >but should Message Expiry be included in XMLP as well? If it does not go in
> >the XMLP spec, then it must go somewhere else, but where and what group
> >should be responsible for defining it. Some options include:
> >1. It's own spec, developed by a separate group - which one
> >2. It's own spec developed as part of RM
> >3. Part of the RM spec
> >
> >This doesn't just apply to Message Expiry and Message Id, it applies to 
> many
> >other areas as well such as:
> >1. Message Routing & Addressing
> >2. Message Content lists
> >3. Choreography Managment
> >etc, etc ...
> >
> >I could go on, but I would like other people's views.
> >
> >David
> >
> >Director, Product Management, Web Services
> >Commerce One
> >4440 Rosewood Drive, Pleasanton, CA 94588, USA
> >Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> ><mailto:david.burdett@commerceone.com;>mailto:david.burdett@commerceone.c 
> om; Web: <http://www.commerceone.com>http://www.commerceone.com