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

Received on Monday, 16 December 2002 02:03:56 UTC