[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. When (and if) we visit the (infamous) Service Interface Layer, there are a few more points we need to look at, anyway. cheers | -----Original Message----- | From: Christopher Ferris [mailto:chris.ferris@sun.com] | Sent: Thursday, December 06, 2001 8:26 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 | | | 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> | > | | | | ---------------------------------------------------------------- | 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