OASIS ebXML Messaging Services TC

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-06-2001 10:07
    
    David,
    
    See 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 03:14:44 PM
    
    To:    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: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
    
    
    
    Marty,
    
    I was suggesting first that we might not need messageOrderSemantics and we
    could
    do away with this attribute.
    
    I was suggesting second, that it is not particularly useful to tie
    MessageOrder
    to ConversationId.  I did not mean to imply that MessageOrder would be
    outside
    the confines of a Conversation.  We have no means of ending a Conversation
    and I
    suspect it will be common for Conversations to never end (why should
    they?).
    
    MWS:  Someone else expressed the view that conversations will always end.
    In my mind,
    applications that are conversation-based will naturally equate a
    conversation with
    one unit of business (e.g. one purchase) and so, conversations will always
    end. I
    suspect that there will be edge cases of legacy software that is not
    ebXML-aware that
    does its own conversation mangement based on information in the payload
    (e.g purchase
    order number).  The MSH might see that as a single never-ending
    conversation.
    
    MWS:  You have to have a means of ending a conversation. You don't actually
    end it.
    The application does that but you have to be notified that the conversation
    is ended
    precisely so you can purge obsolete stuff from the persistent store.  Two
    approaches
    have already been suggested on this list:
    
       1. Software at each party notifies its MSH
       2. Software on the side the sends the last message notifies its MSH and
       the
       message header contains a flag that notifies the To MSH.
    
    We
    do not specify that a ConversationId must be kept in storage anywhere in
    the
    spec.
    
    MWS:  No but since you can (and usually have to) use the convesationId for
    routing,
    there is an implication that you keep information around that enables that
    routing
    to be done.
    Since there is only a single conversationId, one or both parties has to do
    mapping,
    which requires some mapping issue to be kept in the persistent store with
    the
    conversationId.
    There is an alternative which the team rejected at least once:  The
    conversationId
    contains a piece that each party supplies (on the first message exchange)
    and that
    piece is the actual routing information about the conversation. Since the
    actual
    routing information, rather than a label, is in the message header, the MSH
    does
    not have to keep the conversationId and mapping information int he
    persistent store.
    
    I am looking for another way -- say a new set of ordered messages could
    include
    the start number so the Receiving MSH does not have to keep messages past
    persistDuration?
    
    MWS: I think that it has already been pointed out that the whole
    last-ordered message
    does not have to be saved in its entirety until the next in-order message
    arrives; only the
    conversationId, last ordered sequence number, and a few other header things
    have to
    be saved.
    
    I don't know the solution but I think MessageOrder is broken.
    IMO, keeping information in persistent store forever is not the right
    answer,
    
    MWS: Again, mostly not forever since most conversations end.
    
    but I will go with that if it will get us past this problem.
    
    David.