[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
Marty, you are absolutely correct! Every word is right! I never said a Conversation ended with persistDuration. David. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, December 04, 2001 7:46 AM To: David Fischer Cc: Ralph Berwanger; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId Not true! The fact that no more messages for a conversation are left in the persistent store does not mean that the conversation is ended. The time to complete a conversation may far exceed persistDuration. In addition to network delay and MSH response time, it may involve long processing delays by the application. Just consider the case where you order a custom-built PC from a company with just-in-time inventory policy. It may have to place orders with multiple subcontractors and wait for responses to all of them before it replies to you. The MSH can only conclude that a conversation is ended when it is told that it is ended, preferably by the software/middleware above it. Most useful conversations eventually end. Yes, there are some that go on forever. An application may open a conversation and use it for a continuing flow of individual interactions. In my experience that happens when some of the needed identifiers are in payload where they are hidden from the middleware. OBI is probably one such case. Applications supporting ebXML messaging probably do not need infinite length conversations. In any case if this is done right, the MSH need not care, i.e. if conversation management is above the level of the MSH. 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:30:08 PM To: Ralph Berwanger <rberwanger@bTrade.com>, ebxml-msg@lists.oasis-open.org cc: Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId Ralph, Chris, I agree. What I was trying to point out is that (purely for the purposes of Message Order) the ConversationId need not be stored separately in persistent store from the messages pertaining to the ConversationId. If there are no messages in the persistent store pertaining to a conversation, then there is no need to store it any longer for the purposes of maintaining message order. You are of course correct, a ConversationId may be used again later. IMO, a Conversation may never actually end. Regards, David Fischer Drummond Group. -----Original Message----- From: Ralph Berwanger [mailto:rberwanger@bTrade.com] Sent: Monday, December 03, 2001 3:27 PM To: ebxml-msg@lists.oasis-open.org 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> ---------------------------------------------------------------- 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