+1
Doug Bunting wrote:
> David,
>
> This doesn't have the appearance of a non-normative note. And, as Marty has
> mentioned, it may be worthwhile limiting this to a disclaimer:
> "persistDuration doesn't have anything to do with message order
> implementation." Some explanation might be sensible.
>
> This goes the other way, recommending a specific implementation.
>
> I recommended, in my comments on the schema and the second half, removal of
> the messageOrderSemantics attribute and requiring SequenceNumber in
> MessageOrder. The current module is more complicated than necessary,
> seemingly allowing a sender to provide information the receiver can randomly
> choose to use. It raises a red flag to see text like "X element MUST appear
> when Y attribute has the value Z".
>
> thanx,
> doug
>
> ----- Original Message -----
> From: "David Fischer" <>
> To: "Martin W Sachs" <>; "Christopher Ferris"
> <>
> Cc: "Dan Weinreb" <>; <>
> Sent: Wednesday, 05 December 2001 06:59
> 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).
>
> Does this meet everyone's requirements? I think we will get some flack
> since
> this guarantees slow accumulation of old ConversationIds in persistent
> Storage.
> 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.
>
> Regards,
>
> David.
> -----Original Message-----
> From: Martin W Sachs [mailto:]
> Sent: Wednesday, December 05, 2001 8:08 AM
> To: Christopher Ferris
> Cc: David Fischer; Dan Weinreb;
> Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> You need to say enough in the MSG spec to inform an implementer that
> persistDuration follows different rules for conversationId and
> last-ordered-message than for reliable messaging. Considering the amount
> of discussion we have had on this point, we cannot assume that a
> "reasonable implementer" will know what to do. There are plenty of examples
> in the newspapers about deadly mistakes made by reasonable implementers.
> The Risks Forum mut be full of them.
>
> 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
> ****************************************************************************
> ****
> *****
>
>
>
> Christopher Ferris <> on 12/04/2001 09:39:42 PM
>
> To: David Fischer <>
> cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb <>,
>
> Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> The thing I have trouble with here is why we have to say anything
> in the spec. This is too suggestive of implementation detail
> IMO (although probably accurate). Why do we need to say anything
> about this at all?
>
> Cheers,
>
> Chris
>
> David Fischer wrote:
>
>
>>OK, I think that will work, but it is not the whole message which needs
>>
> to be
>
>>saved. Once the message is delivered to the application, just the
>>
> MessageId,
>
>>CPAId, persistDuration, ConversationId, SequenceNumber (did I get
>>
> everything?)
>
>>need to be saved. The spec says now only the MessageId needs to be saved
>>
> but
>
>>that's not enough for MessageOrder.
>>
>>David.
>>
>>-----Original Message-----
>>From: Martin W Sachs [mailto:]
>>Sent: Tuesday, December 04, 2001 5:01 PM
>>To: Christopher Ferris
>>Cc: David Fischer; Dan Weinreb; ;
>>
>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>
>>
>>
>>Then it should only be necessary to add to the MSG spec words that say:
>>
>> The MSH shall preserve in persistent storage the last message in the
>> conversation that was sent in order to the application until either a
>> subseqent in-order message arrives or until the conversation ends
>> (regardless of how long that takes). These words probably should be
>> modified if preserving some header information is all that is needed.
>>
>> The MSH shall preserve in persistent storage the conversationId of an
>> in-progress conversation until that conversation ends (no matter how
>> long that takes).
>>
>>
>>No change is needed to the CPPA spec unless it now does not say that
>>persistDuration is the mininum length of time... (see Chris' words
>>
> below).
>
>>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
>>
>>
> ****************************************************************************
> ****
>
>
>>*****
>>
>>
>>
>>Christopher Ferris <> on 12/04/2001 05:46:11 PM
>>
>>To: Martin W Sachs/Watson/IBM@IBMUS
>>cc: David Fischer <>, Dan Weinreb
>> <>,
>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>
>>
>>
>>right now, the spec suggests #1 which is that pd is the
>>minimum length of time that a party will commit to
>>preserving a message (or its relevant artifacts) in
>>persistent store for purposes of filtering duplicate
>>messages.
>>
>>Cheers,
>>
>>Chris
>>
>>Martin W Sachs wrote:
>>
>>
>>
>>>One of these possibilities:
>>>
>>>1. If the MSG spec states that persistDuration is a minimum length of
>>>
>>>
>>time,
>>
>>
>>>then all you need is to add words to the MSG spec conveying additional
>>>rules when message ordering is in effect.
>>>
>>>2. If the MSG spec states that messages that live until persistDuration
>>>MUST be discarded right away, then we probably need additional text in
>>>
>>>
>>both
>>
>>
>>>the MSG and the CPA spec.
>>>
>>>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 <> on 12/04/2001 02:39:43 PM
>>>
>>>To: Martin W Sachs/Watson/IBM@IBMUS
>>>cc: Dan Weinreb <>,
>>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>>
>>>
>>>
>>>Yes Marty, absolutely. I think there are potential problems (discussed
>>>below)
>>>which make MessageOrder quite fragile. I am shuddering over the thought
>>>
>>>
>>of
>>
>>
>>>changing the persistDuration rules depending upon whether or not
>>>MessageOrder is
>>>present (wouldn't this constitute a CPA override!).
>>>
>>>I still like your other solution.
>>>
>>>Regards,
>>>
>>>David Fischer
>>>Drummond Group.
>>>
>>>-----Original Message-----
>>>From: Martin W Sachs [mailto:]
>>>Sent: Tuesday, December 04, 2001 10:50 AM
>>>To: David Fischer
>>>Cc: Dan Weinreb;
>>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>>
>>>
>>>
>>>Some comments below.
>>>
>>>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 <> on 12/04/2001 11:16:21 AM
>>>
>>>To: Dan Weinreb <>
>>>cc:
>>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>>
>>>
>>>
>>>Dan, did you mean to imply that messages are no longer stored once they
>>>
>>>
>>are
>>
>>
>>>acknowledged? This is not the case. Messages must be stored longer than
>>>persistDuration. In your scenario, when 12 got to the Receiving MSH,
>>>
>>>
>>1-10
>>
>>
>>>are
>>>still in the store. If you wait so long that 1-10 have passed
>>>persistDuration,
>>>then I think you have waited so long that it does not matter any more.
>>>
>>>I see your point about what happens if there is nothing in the store and
>>>the
>>>Receiving MSH gets a message with a number larger than 1. However, this
>>>implies
>>>the last ordered message/MessageId (which has been delivered in order)
>>>
>>>
>>must
>>
>>
>>>be
>>>stored indefinitely (forever?) which is probably not acceptable.
>>>
>>>MWS: For most conversations, there will be an indication of an end, at
>>>which time
>>>the last ordered message can be discarded. I guess if storage is tight,
>>>you
>>>only need to keep the sequence number and conversationId of the last
>>>ordered message
>>>
>>>
>>>This also
>>>points out the conflict between Message Order and persistDuration. What
>>>
>>>
>>if
>>
>>
>>>messages 1,2,3,4 have persistDuration of 2 days. Messages 1,2,4 are
>>>delivered.
>>>The MSH hands 1,2 to the application but holds 4. For some reason, 3 is
>>>not
>>>delivered for 3 days. In this case 3,4 have already passed
>>>
>>>
>>persistDuration
>>
>>
>>>so
>>>they are not delivered. The next day, 5 is delivered. Since 3,4 were
>>>
>>>
>>not
>>
>>
>>>delivered, then 5 cannot be delivered (nor any subsequent messages) even
>>>though
>>>it is still within TTL, and the ordering is forever broken for this
>>>ConversationId. We may have to say Message Ordering does not work if any
>>>message in the order fails to be delivered within its persistDuration (or
>>>maybe
>>>TTL)? Of course, all this can be adjusted at run time by increasing the
>>>value
>>>of persistDuration in the CPA. Once again, MessageOrdering is based on
>>>persistDuration.
>>>
>>>MWS: All of which says that some additional rules are needed on
>>>
>>>
>>discarding
>>
>>
>>>messages
>>>in the presence of ordering. The last ordered message cannot be
>>>
>>>
>>discarded
>>
>>
>>>until
>>>either the next message in the sequence arrives or the application ends
>>>
>>>
>>the
>>
>>
>>>conversation,
>>>regardless of its persist duration. Similary, if there is a gap in the
>>>sequence numbers,
>>>all the out of sequence messages must be preserved, regardless of
>>>persistDuration,
>>>until they can be delivered. The MSG or CPPA specification must provide
>>>advice on
>>>how long to set persistDuration depending on what combination of reliable
>>>messaging
>>>and ordering is being used.
>>>
>>>I am wondering why are we messing with all of this? Did I see Marty
>>>suggest, if
>>>messages are order dependant, just wait for acknowledgment from the end
>>>before
>>>sending the next message? Sounds good.
>>>
>>>MWS: Ahhh... the light begins to dawn.
>>>
>>>Regards,
>>>
>>>David.
>>>
>>>-----Original Message-----
>>>From: Dan Weinreb [mailto:]
>>>Sent: Monday, December 03, 2001 9:40 PM
>>>To:
>>>Cc: ;
>>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>>
>>>
>>> Date: Mon, 03 Dec 2001 20:30:08 -0600
>>> From: David Fischer <>
>>>
>>> If there
>>> are no messages in the persistent store pertaining to a conversation,
>>> then
>>>there
>>> is no need to store it any longer for the purposes of maintaining
>>> message
>>>order.
>>>
>>>I'm not sure that would work. Suppose two parties establish a
>>>conversation with ID 5551212. Party A sends messages numbered 1
>>>through 10 to Party B, and party B's application reads all the
>>>messages and acknowledges them, so that there aren't any messages
>>>still waiting to be delivered to B. Now a message arrives at B with
>>>conversation ID 5551212 and a sequence number of 12. The MSH at B's
>>>end has to realize that is should not deliver this message to the
>>>application because message 11 hasn't arrived yet. So the MSH at B's
>>>end has to be storing somewhere the fact that the most recent message
>>>delivered to the application from conversation 5551212 is 10.
>>>
>>>-- Dan
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
