[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Shimamura-san, I think you are proposing a different algorithm for duplicate elimination with ordering than is the case for reliable messaging without ordering. That is unnecessary added complexity. It is never necessary to preserve the entire message that has been sent to the application for duplicate checking of subsequent messages. All that has to be perserved is the messageId and perhaps some other header information. That isn't much of a burden on persistent store capacity. Regards, Martin Sachs ************************************************************************************* 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 ************************************************************************************* SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> on 12/06/2001 05:32:27 AM To: David Fischer <david@drummondgroup.com>, Martin W Sachs/Watson/IBM@IBMUS cc: Christopher Ferris <chris.ferris@sun.com>, Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org Subject: Re: Comments on the 1.09 about ConversationId David, I guess you think that: Check of duplicate message is prerequisite condition for guarantee of message order. Thus if conversation is scope of guarantee of message order, all the received message's information (MessageId, etc.) in the conversation must be preserved in the Receiving MSH's persistent storage for duplication check until the conversation finishes. But actually, the Receiving MSH can remove received message's information when the message is passed to higher layer (application or middleware) in order and the passed message's persistDuration expires, except for the last received message in order. Because when a message's persistDuration expires, the message is never re-sent to the Receiving MSH: 7.4.6 PersistDuration ... If the PersistDuration has passed since the message was first sent, a Sending MSH SHOULD NOT resend a message with the same MessageId. (Line 1616-1617, P.39, V1.09) On Wed, 05 Dec 2001 14:27:31 -0600 David Fischer <david@drummondgroup.com> wrote: > Oh wait! We can just use the "reset" feature after all the previous messages > pass persistDuration. If we do that, we don't need to keep the messages past > persistDuration. > > Regards, > > David. > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Wednesday, December 05, 2001 10:21 AM > To: David Fischer > Cc: Christopher Ferris; Dan Weinreb; ebxml-msg@lists.oasis-open.org > Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId > > > > Some comments below, MWS: > > 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/05/2001 09:59:17 AM > > To: Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris > <chris.ferris@sun.com> > cc: Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org > 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). > > MWS: I still think that a non-normative reminder is needed that these > holding > times might exceed the value of persistDuration > > Does this meet everyone's requirements? I think we will get some flack > since > this guarantees slow accumulation of old ConversationIds in persistent > Storage. > > MWS: You can't avoid accumulating old conversationIds since a conversation > can last a long time. The conversationIds will eventually be purged as > each > conversation ends. A never-ending conversation will only contribute one > conversationId, so it shouldn't be a big deal. > > 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. > > MWS: As long as the sequencing is within a conversation, that's the way it > is. > If you try to do message ordering over the entire stream, you need sequence > numbers across the entire stream and you are spinning your wheels ordering > message that have no functional time relationship to each other. > > Regards, > > David. Regards, -- SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783) Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC