[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
+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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC