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

[SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>]

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