OASIS ebXML Messaging Services TC

 View Only

Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement

  • 1.  Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement

    Posted 12-11-2001 19:00
    This is getting a bit confused and I apologise for adding to the confusion.
    
    David, I believe you've agreed with me in general and then taken a stance
    different than mine.  That's fine but I'll still attempt to clear up the
    disparity.  One note: MSH-level errors allowed after an end-to-end
    acknowledgment completely confuse any state machine at the sender (leaving
    everything indeterminate until long after TimeToLive has expired), means
    retries might be necessary after an acknowledgment and / or goes against our
    requirement that manual intervention or an acknowledgment are the only ways
    to end the reliable messaging cycle.
    
    Martin, I would agree completely with your statements about acknowledgments
    recognising placement of a message in the persistent store if and only if we
    made it clear that store was our mechanism for transfers to the application
    space.  The current specification doesn't recognise that and doesn't require
    any use of the persistent store except with regard to reliable messaging and
    duplicate detection.  We don't even say the persistent store is logically
    part of both the application and the MSH implementation.
    
    Back to the original issue: What event(s) MUST occur prior to the
    TimeToLive?  Arvola is absolutely correct in saying the current "delivered
    and processed" wording uses an event far too late.  That definition would
    require some MSH control over application processing timelines.
    
    David F. seems to be suggesting TimeToLive should be checked only upon
    receipt of a message.  That definitely occurs prior to sending an
    acknowledgment message but seems like an event immaterial to the sender.  An
    infinite-length queue or even no connection at all between the receiving MSH
    and To Party application would become a reasonable implementation.
    
    I'd prefer a middle ground.  The message is logically received, validated,
    placed in persistent storage, acknowledged, processed by the application and
    (optionally) responded to at a business level.  Use of the "placed in
    persistent storage" event would be fine.  With Martin's interpretation of
    "placed in persistent storage" as being semantically identical to "passed to
    the application", it gets even better but I think we can avoid requiring
    that being explicit in our specification.
    
    thanx,
        doug