OASIS ebXML Messaging Services TC

 View Only
Back to discussions
Expand all | Collapse all

[ebxml-msg] Re: Comments on the 1.09 about ConversationId

  • 1.  [ebxml-msg] Re: Comments on the 1.09 about ConversationId

    Posted 12-06-2001 10:33 
    
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.
>
>


Related Content