OASIS ebXML Messaging Services TC

Re: [ebxml-msg] Re: Use cases for messageOrdering

  • 1.  Re: [ebxml-msg] Re: Use cases for messageOrdering

    Posted 11-30-2001 20:09
    
    Arvola,
    
    Thank you for providing this information.
    
    Just one point:  Your discussion of multiple concurrent instantiations of a
    PIP is presumably not relevant to the message ordering issue since (I
    assume) that each instantiation would be a separate conversation.
    
    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
    *************************************************************************************
    
    
    
    Arvola Chan <arvola@tibco.com> on 11/30/2001 07:53:39 PM
    
    To:    Jacques Durand <JDurand@fs.fujitsu.com>, Martin W
           Sachs/Watson/IBM@IBMUS
    cc:    ebxml-msg@lists.oasis-open.org
    Subject:    Re: [ebxml-msg] Re: Use cases for messageOrdering
    
    
    
    
    Jacques:
    
    Let me quote one particular subsection in the RNIF 2.0  specification:
    
    
    2.6.6 Handling Retries and Late  Acknowledgments
    
    
    As established earlier, the trading partner sending an  action message
    retries the message until either a Signal (Receipt Acknowledgment  or
    Exception) is received or a timeout condition occurs. Hence, the receiver
    MUST be prepared to receive the same action message more than once. In such
    a  case, if the action requires a ReceiptAcknowledgment, the Receipt
    Acknowledgment  (or Exception if there is a failure)MUST be resent. Also,
    as mentioned earlier,  the PIP choreography is independent of the transfer
    or transport mechanisms.  Therefore, it is possible that for a given
    request, the Receipt Acknowledgment  can arrive after the response message.
    This MUST NOT be deemed as an  out-of-order message. If the response is
    received before the Receipt  Acknowledgment and the request action requires
    non-repudiation of receipt, then  any of the following suggested approaches
    MAY be followed.
    
    A response that arrives before the Receipt Acknowledgment  MAY either be
    queued for processing until the Receipt Acknowledgment is received  or
    processed immediately. If the response is processed immediately, then the
    process SHALL NOT be completed until the Receipt Acknowledgment is
    received,  since the Receipt Acknowledgment contains the digest information
    for  non-repudiation of receipt. These approaches are suggestive only and
    the  implementer is free to choose a similar approach as long as the result
    is the  same (i.e., the response SHALL NOT be rejected unless a timeout
    occurs waiting  for the Receipt Acknowledgment).
    Thus, the RosettaNet Implementation Framework does not assume  that
    messages will always arrive in the same order as being sent. The receiver
    is expected to do some bufferring to deal with messages that arrive out of
    sequence, rather than raising exceptions immediately.
    
    The sequence diagrams you�have seen in RosettaNet PIP  specifications are
    with respect to a single instance of that PIP's execution. I  don't recall
    PIP specifications stating whether multiple instantiations can be  active
    concurrently but I believe typical implementations would allow concurrent
    instantiations of the same PIP.
    
    Regards,
    -Arvola