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 19:56
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ebxml-msg message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


    Title: 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