RE: Message Expiry

Ricky

You wrote ...

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

Your conclusion is correct, the sender cannot conclude, with ABSOLUTE
certainty that a message was not delivered if no ack is was received before
the time expired.

I also agree that time expiry does not actually increas the reliability of
message delivery.

What it does do, is increase the confidence of the sender that the message
was not delivered and/or was not processed as:
1. No acks were received even after repeated sending of the message -
suggesting that the destination is not accepting messages
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.

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]
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; Web: http://www.commerceone.com