[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
I don't think that we need to say anything about this at all. As Marty has indicated, control over the conversation is within the application/process management domain, not the MSH. If anything, this would be something in the realm of the infamous Service Interface layer and not part of this spec. We're writing a protocol spec, not an implementation design specification. Cheers, Chris David Fischer wrote: > I'm sorry, I was not clear enough. > > Conversations may not end, from the MSH perspective, because there is no > notification to the MSH that a Conversation has ended -- at least we have not > identified such a thing. If we would specify such a thing, the notification > must be made to both ends of the Conversation. > > This sounds like new functionality. > > Regards, > > David. > > -----Original Message----- > From: Ralph Berwanger [mailto:rberwanger@bTrade.com] > Sent: Thursday, December 06, 2001 9:13 AM > To: ebxml-msg@lists.oasis-open.org > Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId > > > Marty, > Speaking from the legacy community point-of-view, we have been > discussing the fact that each EDI interchange (set of purchase orders) > would be a unique conversation. I cannot recall a single discussion > where the concept of a never-ending conversation came up (except for a > couple standards bodies but that is a different subject all together). > That does not mean that you are not correct in the assumption, only that > it appears contrary to my experience. Also, I said that I do not > 'recall' and that can provide some hints to my baseline. > > Ralph > ASC X12, Vice Chair > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Thursday, December 06, 2001 9:05 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 > > > > David, > > See 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 03:14:44 PM > > To: Martin W Sachs/Watson/IBM@IBMUS > cc: Christopher Ferris <chris.ferris@sun.com>, Dan Weinreb > <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org > Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about > ConversationId > > > > Marty, > > I was suggesting first that we might not need messageOrderSemantics and > we > could > do away with this attribute. > > I was suggesting second, that it is not particularly useful to tie > MessageOrder > to ConversationId. I did not mean to imply that MessageOrder would be > outside > the confines of a Conversation. We have no means of ending a > Conversation > and I > suspect it will be common for Conversations to never end (why should > they?). > > MWS: Someone else expressed the view that conversations will always > end. > In my mind, > applications that are conversation-based will naturally equate a > conversation with > one unit of business (e.g. one purchase) and so, conversations will > always > end. I > suspect that there will be edge cases of legacy software that is not > ebXML-aware that > does its own conversation mangement based on information in the payload > (e.g purchase > order number). The MSH might see that as a single never-ending > conversation. > > MWS: You have to have a means of ending a conversation. You don't > actually > end it. > The application does that but you have to be notified that the > conversation > is ended > precisely so you can purge obsolete stuff from the persistent store. > Two > approaches > have already been suggested on this list: > > 1. Software at each party notifies its MSH > 2. Software on the side the sends the last message notifies its MSH > and > the > message header contains a flag that notifies the To MSH. > > We > do not specify that a ConversationId must be kept in storage anywhere in > the > spec. > > MWS: No but since you can (and usually have to) use the convesationId > for > routing, > there is an implication that you keep information around that enables > that > routing > to be done. > Since there is only a single conversationId, one or both parties has to > do > mapping, > which requires some mapping issue to be kept in the persistent store > with > the > conversationId. > There is an alternative which the team rejected at least once: The > conversationId > contains a piece that each party supplies (on the first message > exchange) > and that > piece is the actual routing information about the conversation. Since > the > actual > routing information, rather than a label, is in the message header, the > MSH > does > not have to keep the conversationId and mapping information int he > persistent store. > > I am looking for another way -- say a new set of ordered messages could > include > the start number so the Receiving MSH does not have to keep messages > past > persistDuration? > > MWS: I think that it has already been pointed out that the whole > last-ordered message > does not have to be saved in its entirety until the next in-order > message > arrives; only the > conversationId, last ordered sequence number, and a few other header > things > have to > be saved. > > I don't know the solution but I think MessageOrder is broken. > IMO, keeping information in persistent store forever is not the right > answer, > > MWS: Again, mostly not forever since most conversations end. > > but I will go with that if it will get us past this problem. > > 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. > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Wednesday, December 05, 2001 8:08 AM > To: Christopher Ferris > Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org > Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId > > > > You need to say enough in the MSG spec to inform an implementer that > persistDuration follows different rules for conversationId and > last-ordered-message than for reliable messaging. Considering the > amount > of discussion we have had on this point, we cannot assume that a > "reasonable implementer" will know what to do. There are plenty of > examples > in the newspapers about deadly mistakes made by reasonable implementers. > The Risks Forum mut be full of them. > > 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 > ************************************************************************ > ******** > > > ***** > > > > Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 09:39:42 PM > > To: David Fischer <david@drummondgroup.com> > cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb > <dlw@exceloncorp.com>, > ebxml-msg@lists.oasis-open.org > Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about > ConversationId > > > > The thing I have trouble with here is why we have to say anything > in the spec. This is too suggestive of implementation detail > IMO (although probably accurate). Why do we need to say anything > about this at all? > > Cheers, > > Chris > > David Fischer wrote: > > >>OK, I think that will work, but it is not the whole message which >> > needs > to be > >>saved. Once the message is delivered to the application, just the >> > MessageId, > >>CPAId, persistDuration, ConversationId, SequenceNumber (did I get >> > everything?) > >>need to be saved. The spec says now only the MessageId needs to be >> > saved > but > >>that's not enough for MessageOrder. >> >>David. >> >>-----Original Message----- >>From: Martin W Sachs [mailto:mwsachs@us.ibm.com] >>Sent: Tuesday, December 04, 2001 5:01 PM >>To: Christopher Ferris >>Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org; >>ebxml-cppa@lists.oasis-open.org >>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId >> >> >> >>Then it should only be necessary to add to the MSG spec words that >> > say: > >> The MSH shall preserve in persistent storage the last message in >> > the > >> conversation that was sent in order to the application until either >> > a > >> subseqent in-order message arrives or until the conversation ends >> (regardless of how long that takes). These words probably should be >> modified if preserving some header information is all that is >> > needed. > >> The MSH shall preserve in persistent storage the conversationId of >> > an > >> in-progress conversation until that conversation ends (no matter >> > how > >> long that takes). >> >> >>No change is needed to the CPPA spec unless it now does not say that >>persistDuration is the mininum length of time... (see Chris' words >> > below). > >>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 >> >> > ************************************************************************ > ******** > > > > >>***** >> >> >> >>Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 05:46:11 PM >> >>To: Martin W Sachs/Watson/IBM@IBMUS >>cc: David Fischer <david@drummondgroup.com>, Dan Weinreb >> <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org >>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about >> > ConversationId > >> >> >>right now, the spec suggests #1 which is that pd is the >>minimum length of time that a party will commit to >>preserving a message (or its relevant artifacts) in >>persistent store for purposes of filtering duplicate >>messages. >> >>Cheers, >> >>Chris >> >>Martin W Sachs wrote: >> >> >> >>>One of these possibilities: >>> >>>1. If the MSG spec states that persistDuration is a minimum length of >>> >>> >>time, >> >> >>>then all you need is to add words to the MSG spec conveying additional >>>rules when message ordering is in effect. >>> >>>2. If the MSG spec states that messages that live until >>> > persistDuration > >>>MUST be discarded right away, then we probably need additional text in >>> >>> >>both >> >> >>>the MSG and the CPA spec. >>> >>>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/04/2001 02:39:43 PM >>> >>>To: Martin W Sachs/Watson/IBM@IBMUS >>>cc: Dan Weinreb <dlw@exceloncorp.com>, >>> > ebxml-msg@lists.oasis-open.org > >>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about >>> > ConversationId > >>> >>> >>>Yes Marty, absolutely. I think there are potential problems >>> > (discussed > >>>below) >>>which make MessageOrder quite fragile. I am shuddering over the >>> > thought > >>of >> >> >>>changing the persistDuration rules depending upon whether or not >>>MessageOrder is >>>present (wouldn't this constitute a CPA override!). >>> >>>I still like your other solution. >>> >>>Regards, >>> >>>David Fischer >>>Drummond Group. >>> >>>-----Original Message----- >>>From: Martin W Sachs [mailto:mwsachs@us.ibm.com] >>>Sent: Tuesday, December 04, 2001 10:50 AM >>>To: David Fischer >>>Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org >>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId >>> >>> >>> >>>Some comments below. >>> >>>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/04/2001 11:16:21 AM >>> >>>To: Dan Weinreb <dlw@exceloncorp.com> >>>cc: ebxml-msg@lists.oasis-open.org >>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about >>> > ConversationId > >>> >>> >>>Dan, did you mean to imply that messages are no longer stored once >>> > they > >>are >> >> >>>acknowledged? This is not the case. Messages must be stored longer >>> > than > >>>persistDuration. In your scenario, when 12 got to the Receiving MSH, >>> >>> >>1-10 >> >> >>>are >>>still in the store. If you wait so long that 1-10 have passed >>>persistDuration, >>>then I think you have waited so long that it does not matter any more. >>> >>>I see your point about what happens if there is nothing in the store >>> > and > >>>the >>>Receiving MSH gets a message with a number larger than 1. However, >>> > this > >>>implies >>>the last ordered message/MessageId (which has been delivered in order) >>> >>> >>must >> >> >>>be >>>stored indefinitely (forever?) which is probably not acceptable. >>> >>>MWS: For most conversations, there will be an indication of an end, >>> > at > >>>which time >>>the last ordered message can be discarded. I guess if storage is >>> > tight, > >>>you >>>only need to keep the sequence number and conversationId of the last >>>ordered message >>> >>> >>>This also >>>points out the conflict between Message Order and persistDuration. >>> > What > >>if >> >> >>>messages 1,2,3,4 have persistDuration of 2 days. Messages 1,2,4 are >>>delivered. >>>The MSH hands 1,2 to the application but holds 4. For some reason, 3 >>> > is > >>>not >>>delivered for 3 days. In this case 3,4 have already passed >>> >>> >>persistDuration >> >> >>>so >>>they are not delivered. The next day, 5 is delivered. Since 3,4 were >>> >>> >>not >> >> >>>delivered, then 5 cannot be delivered (nor any subsequent messages) >>> > even > >>>though >>>it is still within TTL, and the ordering is forever broken for this >>>ConversationId. We may have to say Message Ordering does not work if >>> > any > >>>message in the order fails to be delivered within its persistDuration >>> > (or > >>>maybe >>>TTL)? Of course, all this can be adjusted at run time by increasing >>> > the > >>>value >>>of persistDuration in the CPA. Once again, MessageOrdering is based >>> > on > >>>persistDuration. >>> >>>MWS: All of which says that some additional rules are needed on >>> >>> >>discarding >> >> >>>messages >>>in the presence of ordering. The last ordered message cannot be >>> >>> >>discarded >> >> >>>until >>>either the next message in the sequence arrives or the application >>> > ends > >>the >> >> >>>conversation, >>>regardless of its persist duration. Similary, if there is a gap in >>> > the > >>>sequence numbers, >>>all the out of sequence messages must be preserved, regardless of >>>persistDuration, >>>until they can be delivered. The MSG or CPPA specification must >>> > provide > >>>advice on >>>how long to set persistDuration depending on what combination of >>> > reliable > >>>messaging >>>and ordering is being used. >>> >>>I am wondering why are we messing with all of this? Did I see Marty >>>suggest, if >>>messages are order dependant, just wait for acknowledgment from the >>> > end > >>>before >>>sending the next message? Sounds good. >>> >>>MWS: Ahhh... the light begins to dawn. >>> >>>Regards, >>> >>>David. >>> >>>-----Original Message----- >>>From: Dan Weinreb [mailto:dlw@exceloncorp.com] >>>Sent: Monday, December 03, 2001 9:40 PM >>>To: david@drummondgroup.com >>>Cc: rberwanger@btrade.com; ebxml-msg@lists.oasis-open.org >>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId >>> >>> >>> Date: Mon, 03 Dec 2001 20:30:08 -0600 >>> From: David Fischer <david@drummondgroup.com> >>> >>> 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. >>> >>>I'm not sure that would work. Suppose two parties establish a >>>conversation with ID 5551212. Party A sends messages numbered 1 >>>through 10 to Party B, and party B's application reads all the >>>messages and acknowledges them, so that there aren't any messages >>>still waiting to be delivered to B. Now a message arrives at B with >>>conversation ID 5551212 and a sequence number of 12. The MSH at B's >>>end has to realize that is should not deliver this message to the >>>application because message 11 hasn't arrived yet. So the MSH at B's >>>end has to be storing somewhere the fact that the most recent message >>>delivered to the application from conversation 5551212 is 10. >>> >>>-- Dan >>> >>> >>> >>>---------------------------------------------------------------- >>>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> >> > > > > > > > ---------------------------------------------------------------- > 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> > > > ---------------------------------------------------------------- > 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