OASIS ebXML Messaging Services TC

[ebxml-msg] Re: Comments on the 1.09 about ConversationId

  • 1.  [ebxml-msg] Re: Comments on the 1.09 about ConversationId

    Posted 12-06-2001 10:33
    
    Shimamura-san,
    
    I think you are proposing a different algorithm for duplicate elimination
    with ordering than is the case for reliable messaging without ordering.
    That is unnecessary added complexity.
    
    It is never necessary to preserve the entire message that has been sent to
    the application for duplicate checking of subsequent messages.  All that
    has to be perserved is the messageId and perhaps some other header
    information.  That isn't much of a burden on persistent store capacity.
    
    
    Regards,
    Martin Sachs
    
    *************************************************************************************
    
    Martin W. Sachs
    IBM T. J. Watson Research Center
    P. O. B. 704
    Yorktown Hts, NY 10598
    914-784-7287;  IBM tie line 863-7287
    Notes address:  Martin W Sachs/Watson/IBM
    Internet address:  mwsachs @ us.ibm.com
    *************************************************************************************
    
    
    
    SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> on 12/06/2001 05:32:27 AM
    
    To:    David Fischer <david@drummondgroup.com>, Martin W
           Sachs/Watson/IBM@IBMUS
    cc:    Christopher Ferris <chris.ferris@sun.com>, Dan Weinreb
           <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
    Subject:    Re: Comments on the 1.09 about ConversationId
    
    
    
    David,
    
    I guess you think that:
    
        Check of duplicate message is prerequisite condition for guarantee
        of message order. Thus if conversation is scope of guarantee of
        message order, all the received message's information (MessageId,
        etc.) in the conversation must be preserved in the Receiving MSH's
        persistent storage for duplication check until the conversation
        finishes.
    
    But actually, the Receiving MSH can remove received message's
    information when the message is passed to higher layer (application or
    middleware) in order and the passed message's persistDuration expires,
    except for the last received message in order. Because when a message's
    persistDuration expires, the message is never re-sent to the Receiving
    MSH:
    
        7.4.6 PersistDuration
        ...
        If the PersistDuration has passed since the message was first sent,
        a Sending MSH SHOULD NOT resend a message with the same MessageId.
                                               (Line 1616-1617, P.39, V1.09)
    
    
    On Wed, 05 Dec 2001 14:27:31 -0600
    David Fischer <david@drummondgroup.com> wrote:
    > Oh wait!  We can just use the "reset" feature after all the previous
    messages
    > pass persistDuration.  If we do that, we don't need to keep the messages
    past
    > persistDuration.
    >
    > Regards,
    >
    > David.
    >
    >