RE: Message Expiry

Ricky,

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.

arkin

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

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