+1
Martin W Sachs wrote:
> Still not true!
>
> If the MSH bases routing decisions on conversationId, it must hold the
> conversationId until it is told by software/middleware that the
> conversation is ended; forever if necessary. If it does not hold onto the
> conversationId, it will not be able to correctly process messages for the
> same conversation that arrive after it purges the conversationId from its
> persistent store.
>
> This will really work much better if the MSH gets out of this business and
> leaves it to the layer of middleware that manages conversation.
>
> 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/03/2001 09:47:54 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>, Dan Weinreb
> <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> I'm sorry, I think I stirred a hornet's nest.
>
> I do not mean that a Conversation ends with persistDuration. I only meant
> the
> ConversationID need not be stored (for Message Order) if there are no
> persisted
> messages for that ConversationId. The Conversation may go on indefinitely.
>
> Sorry for the confusion,
>
> David.
>
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Monday, December 03, 2001 5:25 PM
> To: David Fischer
> Cc: SHIMAMURA Masayoshi; Dan Weinreb; ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> David,
>
> If things are working right, the end of a conversation should NEVER be
> controlled by persistDuration. The end of a conversation is when the
> application (or conversation management middleware) says that it's the end.
>
> If persistDuration expires before the software says that the conversation
> is ended, it is killing the conversation due to an abnormal condition. I
> hope that the MSH would at least have the decency to notify the upper
> levels that it has killed a conversation. Once the conversation has been
> killed by the MSH, no further messages should be sent with the same
> conversation ID since that would confuse the heck out of the upper levels.
> The possiblity of that happening means that perhaps there should be a
> "start of conversation" indicator in the message header so that a receiving
> MSH can distinguish between the start of a new conversation and belated
> messages for conversations that it has killed.
>
> Note also that persistDuration may have a very different time scale if we
> are going to apply it to the conversationId since a conversation can last
> minutes or longer (maybe even weeks), depending on what is going on in the
> conversation.
>
> All of this suggests that we would do well to leave all conversation
> management, including routing of messages by conversationId, to the upper
> levels. That would avoid the need to figure out how long the MSH has to
> persist a conversationId.
>
> 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/03/2001 03:44:24 PM
>
> To: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>, Dan Weinreb
> <dlw@exceloncorp.com>, Martin W Sachs/Watson/IBM@IBMUS
> cc: ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> I seem to be missing something. The end of a conversation is controlled by
> persistDuration, isn't it? I think the ConversationId is held in
> persistent
> store with the MessageId (at least in the case of MessageOrdering). Along
> with,
> or in, the MessageId record, there must be a persistDuration field. When
> the
> last message in that conversation is deleted from the persistent store
> (persistDuration has passed), wouldn't the ConversationId automatically go
> with
> it? If there are still messages waiting because they are out of order,
> would
> they not also be deleted when persistDuration expires? If you are
> concerned
> with messages going away too quickly, then make persistDuration long.
>
> There is nothing forbidding another later message to be sent with the
> original
> ConversationId but the message order would not be of concern since all the
> previous messages have expired anyway.
>
> Or, are you saying ConversationId is held somewhere else?
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
> Sent: Monday, December 03, 2001 3:54 AM
> To: Dan Weinreb; mwsachs@us.ibm.com
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
> Dan and Martin,
>
> My proposal's purpose is not management of ConversationId by MSH itself.
> Its purpose is prevention of invalid ConversationId and acquisition of
> timing information of the end of conversation in MSH. Because message
> order is guaranteed per conversation. If higher layer (application or
> middleware) gives MSH invalid ConversationId, MSH will fail in guarantee
> of message order. And also if MSH can't know when the conversation
> finishes, MSH can't decide that when the conversation's sequence number
> information can be released from MSH's resource.
>
> So I can withdraw (1) in my proposals below, but I'd like to keep (2) as
> my proposal. Because if higher layer gives MSH the status information
> (Start, Middle, End or Alone), sending MSH and receiving MSH can check
> invalid ConversationId and can know when the conversation finishes.
>
>
> On Thu, 29 Nov 2001 19:39:33 +0900
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> wrote:
>
>>The specification of ConversationId element on page 20 has two problems:
>>
>>1) The value of the ConversationId element is determined by the Party.
>>
>> ConversationId is very important for guarantee of message order.
>> Because message order is guaranteed per each conversation. Thus MSH
>> instead of Party should determines and manages the value of the
>> ConversationId to prevent invalid ConversationId value. I propose
>> following change:
>>
>> Line 823-825
>> ... The Party initiating a conversation determines the value of the
>> ConversationId element that SHALL be reflected in all messages
>> pertaining to that conversation.
>> |
>> V
>> ... The Party indicates start and end of conversation to MSH. The
>> value of the ConversationId element is generated and managed by the
>> MSH.
>>
>>2) Receiving MSH can't know the end of conversation.
>>
>> Receiving MSH holds received conversation's ConversationId in its
>> persistent storage for guarantee of message order. However receiving
>> MSH has not any way to know the end of conversation. Thus receiving
>> MSH don't know when ConversationId's information can be removed from
>> its persistent storage.
>>
>> To resolve the problem, I propose to add status attribute to
>> ConversationId element. The status attribute takes one of following
>> three values:
>> Start: First message in messages belong with the conversation.
>> Middle: A message except for first and last message in messages
>> belong with the conversation.
>> End: Last message in messages belong with the conversation.
>> Alone: First and last message in the conversation which consist
>> of only one message. It MUST be specified when the
>> conversation have only one message.
>>
>
>
> 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
>
>
> ----------------------------------------------------------------
> 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>
>