OASIS ebXML Messaging Services TC

 View Only

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

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

    Posted 12-05-2001 11:24
    
    Some comments below, MWS:
    
    Regards,
    Marty
    
    *************************************************************************************
    
    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
    *************************************************************************************
    
    
    
    David Fischer <david@drummondgroup.com> on 12/05/2001 09:59:17 AM
    
    To:    Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris
           <chris.ferris@sun.com>
    cc:    Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
    Subject:    RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
    
    
    
    Shimamura-san's modification of Marty's words (edited version):
    
       When messageOrderSemantics is set to "Guaranteed", the Receiving MSH
       shall preserve in persistent storage all required SOAP Header
       information, including SequenceNumber, needed to keep the
       Message Order semantics of the last message in the conversation
       sent in order to the application until either a subsequent
       in-order message arrives or until the conversation ends
       (no matter how long the conversation exists).
    
       The Receiving MSH shall preserve in persistent storage the
       ConversationId of an in-progress conversation until that conversation
       ends (no matter how long the conversation exists).
    
    MWS:  I still think that a non-normative reminder is needed that these
    holding
    times might exceed the value of persistDuration
    
    Does this meet everyone's requirements?  I think we will get some flack
    since
    this guarantees slow accumulation of old ConversationIds in persistent
    Storage.
    
    MWS:  You can't avoid accumulating old conversationIds since a conversation
    can last a long time.  The conversationIds will eventually be purged as
    each
    conversation ends.  A never-ending conversation will only contribute one
    conversationId, so it shouldn't be a big deal.
    
    In the second paragraph, do we need to say Conversations with
    messageOrderSemantics set to "Guaranteed"?
    
    Do we need messageOrderSemantics?  If MessageOrder is present, why would
    messageOrderSemantics ever be "NotGuaranteed"?  The problem is MessageOrder
    tied
    to ConversationId.  MessageOrder is a very time limited situation while
    ConversationId can be unlimited -- not a good match.
    
    MWS: As long as the sequencing is within a conversation, that's the way it
    is.
    If you try to do message ordering over the entire stream, you need sequence
    numbers across the entire stream and you are spinning your wheels ordering
    message that have no functional time relationship to each other.
    
    Regards,
    
    David.