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