W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

RE: Message Expiry

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 17 Dec 2002 21:22:43 -0800
To: "Ricky Ho" <riho@cisco.com>, "Burdett, David" <david.burdett@commerceone.com>, "Burdett, David" <david.burdett@commerceone.com>, <www-ws-arch@w3.org>

I agree with you on all of these points.

In my opinion the message expiry serves two purposes.

For the sender this is how to process repeated delivery on its side. The
application uses the expiration time to tell the RM how long to keep
resending the message, indicating that the RM should not resend forever (the
receiver may never go back online). It also allows the RM to calculate the
most effective resend times and to prioritize delivery/resend for messages
that expire sooner than others.

This is actually not that interesting if you have one application and one
RM, but it becomes interesting when you have different type of applications
with different requirements, and also intermediaries.

For the receiver it indicates that they should reject a message that arrives
too late. The message may not be lost in space, it may simply arrive after a
significant duration. Intermediaries may queue the message, go offline, come
back online. Some intermediaries may have their way for handling resend.
Some (like SMTP) may increase the resend interval after each successful
attempt. If your e-mail server has ever been done for half a day you will
notice that some messages arrive the next day because the resend interval
becomes significantly long.

So it doesn't increase the reliability per se, but indicates to the receiver
that a message that arrives too late can be ignored, and allows the RM and
intermediaries to figure out how to best move the message around.


  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Ricky Ho
  Sent: Tuesday, December 17, 2002 8:08 PM
  To: Burdett, David; Burdett, David; www-ws-arch@w3.org
  Subject: 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:

  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
  c) "in-doubt" -- The RM is unsure, so it pass that to the Application

  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.

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

  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.

    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.

  I don't see how the sender can be certain about this.  Think about this
  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 ?

    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

    This why in my description of levels of reliable messaging, there are
levels above level 1.

    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

    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
    this just waste the receiver's effort).  I don't think this expiry time
    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,
    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
    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
    the time expiry has NO effect to improve the reliability of message

    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
    >Message Expiry to illustrate it. Note that I could just as easily have
    >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
    >the ideas in LEVEL 1 of Reliable Messaging that I described, was the
    >that a message expired and should not be processed after a certain
point in
    >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
    >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
    >If the answer is yes, then you can easily include how Message Expiry
    >in the RM spec. But I don't think so this is likely. I can quite
    >sending a message that has an expiry time, but not care if the message
    >delivered. So there is another question ...
    >QUESTION 2.  If the definition of Message Expiry is not in the RM spec,
    >where should it be defined and who should define it?
    >You *might* argue that some very basic headers like MesssageId goes in
    >XMLP spec to support some of the ideas that Assaf has been putting
    >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
    >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.
    >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 Wednesday, 18 December 2002 00:23:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC