[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] Reliable / Duplicate / Message Order Inconsistencies
I don't think we have achieved technical consistency among these three features.
7.4.1 first bullet states that "If DuplicateElimination is present - the To Party MSH must persist messages in a persistent store so that duplicate messages will be presented to the To Party Application At-Most-Once, or"
But 7.1 only requires a Receiving MSH save the MessageID in persistent storage, not the messages.
7.5.1 step 5 states: "Wait for the return of an Acknowledgement Message ..."
But 7.4.1 paragraph 3 does not require the use of Acknowledgement Messages
10.1.1 paragraph 2 states: "A MSH that receives a message with a SequenceNumber element MUST NOT pass the message to an application as long as the storage required to save out-of-sequence messages is within defined implementation limits and until all the messages with a lower SequenceNumber have been received and passed to the application.
But 7.5.2 states: If an AckRequested element is present (not an Acknowledgement Message) then:"
"1 If the message is a duplicate (...) generate an AcknowledgementMessage ..."
2 ... b Generate an Acknowledgment message ... Delivery of an Acknowledgement Message constitutes an obligation by the Receiving MSH to deliver the message to the application or forward to the next MSH in the message path as appropriate.
[Side Note: An intermediate MSH isn't supposed to care about all this duplicate stuff, but the wording above suggests it would know]
And while 7.5 paragraph 2 states: The receipt of the Acknowledgement Message indicates that the message being acknowledged has been successfully received and either processed or persisted by the Receiving MSH", the delivery obligation in 7.5.2 would seem to prevent the return of an acknowledgement (if a prior message is still missing) (Catch 22).
Powered by eList eXpress LLC