[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
David, I am not sure that I agree with this. I thought that persistentDuration was related to a specific message. I am thinking about the case when the intermediate message may be a price quote and the price quote is only valid for a few hours. The persistDuration would be set to expire after the termination of the validity period for the quote. However, the conversation would still be open. I can think of several business cases where the persistDuration makes sense on a per message basis (not to be confused with perMessage) and not based on the conversation. Ralph Berwanger David Fischer wrote: > 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