[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
+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" <david@drummondgroup.com> > To: "Martin W Sachs" <mwsachs@us.ibm.com>; "Christopher Ferris" > <chris.ferris@sun.com> > Cc: "Dan Weinreb" <dlw@exceloncorp.com>; <ebxml-msg@lists.oasis-open.org> > 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:mwsachs@us.ibm.com] > Sent: Wednesday, December 05, 2001 8:08 AM > To: Christopher Ferris > Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org > 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 <chris.ferris@sun.com> on 12/04/2001 09:39:42 PM > > To: David Fischer <david@drummondgroup.com> > cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb <dlw@exceloncorp.com>, > ebxml-msg@lists.oasis-open.org > 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:mwsachs@us.ibm.com] >>Sent: Tuesday, December 04, 2001 5:01 PM >>To: Christopher Ferris >>Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org; >>ebxml-cppa@lists.oasis-open.org >>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 <chris.ferris@sun.com> on 12/04/2001 05:46:11 PM >> >>To: Martin W Sachs/Watson/IBM@IBMUS >>cc: David Fischer <david@drummondgroup.com>, Dan Weinreb >> <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org >>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 <david@drummondgroup.com> on 12/04/2001 02:39:43 PM >>> >>>To: Martin W Sachs/Watson/IBM@IBMUS >>>cc: Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org >>>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:mwsachs@us.ibm.com] >>>Sent: Tuesday, December 04, 2001 10:50 AM >>>To: David Fischer >>>Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org >>>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 <david@drummondgroup.com> on 12/04/2001 11:16:21 AM >>> >>>To: Dan Weinreb <dlw@exceloncorp.com> >>>cc: ebxml-msg@lists.oasis-open.org >>>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:dlw@exceloncorp.com] >>>Sent: Monday, December 03, 2001 9:40 PM >>>To: david@drummondgroup.com >>>Cc: rberwanger@btrade.com; ebxml-msg@lists.oasis-open.org >>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId >>> >>> >>> Date: Mon, 03 Dec 2001 20:30:08 -0600 >>> From: David Fischer <david@drummondgroup.com> >>> >>> 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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC