[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo
David, With regard to the second paragraph in your posting, see my comment in line, headed by 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 08/26/2001 06:44:18 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: Arvola Chan <arvola@tibco.com>, Burdett David <david.burdett@commerceone.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org> Subject: RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo We were discussing (I think) the handling of duplicates. The ends would use MessageId as the sole arbitrator of duplicates (if you get a Message with a MessageId which has already been received, it is a duplicate) while IMs would have to consider both MessageId & RetryCount (RetryCount doesn't currently exist, we are suggesting it as an addition). RetryCount would ONLY be set by the From Party MSH. My comments about only the IMs needing RetryCount had to do with duplicate detection. If you were to use RetryCount for some other purpose as well, I would not object. You commented in another eMail about having the To Party count the number of receives of the same message and if it is the same as Retries then. . .do something. One of the fallouts of not requiring CPAs is that the To Party may not know the value of Retries. MWS: If this were the case, B2B would simply not work. All the parameters in the CPA must be agreed to one way or another. Without a CPA, the two parties must communicate by phone, fax, or whatever in order to reach an agreement on all of the parameters necessary for message exchanges and executing the same collaboration protocol. They then have to separately enter them into their systems and somehow assure each other that they have entered compatible configurations. With a CPA, the agreed parameters are recorded in the CPA. Identical CPAs can then be installed by an installation tool in the two systems, to guarantee that the two parties are compatible configured. MWS: The CPA can be very simple for marketplaces mediated by intermediaries who dictate most or all of the configuration parameters. However that makes no provision for communicating between partners on different "intermediary" networks. There are no longer any common parameter and since we do not carry Retries in MessageHeader, the To Party may not know its value. The same is true of RetryInterval and PersistDuration and SyncReply etc. Anything not carried in MessageHeader may not be known by the receiver. This is not always a problem since Retries and RetryInterval are sender-only parameters. PersistDuration is a receiver-only parameter. SyncReply, well, that's both? RetryCount, while it would only be set by the From Party MSH, would be an IM parameter and thus its home in the Via seems like a good choice. MWS: I think that my above comment covers all the points in this paragraph. Again: lack of a CPA does not mean that the two partners do not have to know all these things about each other - it just makes it difficult for them to find out. Regards, David Fischer Drummond Group -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Sunday, August 26, 2001 5:24 PM To: David Fischer Cc: Arvola Chan; Burdett David; ebXML Msg Subject: RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo I don't understand. RetryCount is for end to end RM as well as (probably) for intermediaries. A RetryCount element may be needed in both places, but let's not forget the end to end case. 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 08/26/2001 12:57:33 PM To: Arvola Chan <arvola@tibco.com>, Burdett David <david.burdett@commerceone.com> cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> Subject: RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo RetryCount is another issue. This solution is fine with me but we need to put it in Via rather than my original suggestion of an attribute on MessageId (signature problems). Since it is only for the IMs, the Via seems appropriate? How do we know when to include Via? Our discussions are making me think it will always need to be present. Regards, David Fischer Drummond Group. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Friday, August 24, 2001 8:14 PM To: Burdett David; 'David Fischer' Cc: ebXML Msg Subject: Re: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo David and David: Are you saying that a sending MSH must retry either if an intermediate Ack has not been received or if the end-to-end DeliveryReceipt has not been received, and that the resent message should carry an incremented retry count if it is being resent due to non-receipt of the end-to-end DeliveryReceipt? If so, do we need two sets of retry parameters (i.e., retry count and retry interval) to govern the two different kinds of retry? Thanks, -Arvola -----Original Message----- From: Burdett, David <david.burdett@commerceone.com> To: 'David Fischer' <david@drummondgroup.com>; Arvola Chan <arvola@tibco.com> Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> Date: Friday, August 24, 2001 5:46 PM Subject: RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo >David > >I largely agree with you specifically see below marked with <db></db> > >David > > >-----Original Message----- >From: David Fischer [mailto:david@drummondgroup.com] >Sent: Thursday, August 16, 2001 4:14 PM >To: Arvola Chan >Cc: ebXML Msg >Subject: RE: T2, Proposed solution for ... Re: SyncReply and >ReliableMessagingMethod in QualityOfServiceInfo > > >Arvola, > ><df> comments inline </df> > >David Fischer >Drummond Group. >-----Original Message----- >From: Arvola Chan [mailto:arvola@tibco.com] >Sent: Tuesday, August 14, 2001 10:35 AM >To: HUGHESJIM (HP-Cupertinoex1); ebXML Messaging (E-mail) >Subject: Re: T2, Proposed solution for ... Re: SyncReply and >ReliableMessagingMethod in QualityOfServiceInfo > > >My opinion is that the current spec is so broken that extensive >changes may be necessary to get end to end reliable messaging >over multiple hops to work properly. I agree with you and that >intermediate Acks used by the intermediaries are the likely source >of the problem. ><df> agreed </df> > >If we stipulate that only the sending MSH and the receiving MSH >adopt the reliable messaging behavior, I believe end to end reliable >messaging will work regardless of whether intermediaries are >present. However, this may make reliable messaging not very >useful for certain use cases, e.g., where the sending MSH does >not have a permanent Internet presence. > ><df> This is not all that hard if we keep the present structure of >DeliveryReceipt as the end-to-end Ack and the Acknowledgement element as the >IM >hop Ack. ><db>Agreed</db> >This is already in the spec and nothing about these elements needs to >be changed. We only need to specify in section 10 that if the To Party MSH >gets >a DeliverySemantics=1&o1 then send a DeliveryReceipt to the From Party MSH >(along with ...). ><db>I think I agree.</db> > >Unfortunately, this does not deal with the duplicate problem. If I (the >From >Party MSH) don't get a DR back, then I will retry (Retries and RetryInterval >are >end-to-end parameters, not hop-to-hop). I don't want any IMs rejecting my >retry >due to duplicates. We can fix this by either: > 1) telling the IMs not to worry about duplicates or > 2) add a RetryCount attribute and change the way > IMs handle duplicates. ><db>I think that a Retry Count is the best way to go handle this rather than >a different MessageId that I suggested earlier.</db> > >The way we handle duplicates now is definitely broke. </df> > >I now realize there is a problem in my previous proposal to have >the sending MSH stop retrying once it gets an Ack from the next >intermediary, and then wait for the DeliveryReceipt from the >receiving MSH. Unless the DeliveryReceipt is sent reliably, it >may get lost, so the sending MSH may falsely notify the sending >application that reliable messaging has failed. ><db>Yes and no. If the DR is being sent asynchronously on a spearate session >then it needs to be sent reliably. If it is being sent synchronously on the >same channel then the DR is the acknowledgement and so does not need to be >sent reliably.</db> > >If the DeliveryReceipt >is sent reliably, then it may require end to end acknowledgement >from the sending MSH, possibly triggering an infinite chain of >DeliveryReceipt messages. (A possible workaround may be to >require that if a DeliveryReceipt is sent reliably and on its own, >then it must not request for DeliveryReceipt.) > ><df> agreed -- no DR for a DR and no Ack for an Ack and no Error on an >Error. ><db>Completely agree</db> >We can get carried away with RM if we start sending Acknowledgements or DR >reliably. We also have to pick either Ack on Error or Error on Ack but not >both. I think I prefer Error on Ack... I'm not sure? ><db>This depends on whether the original message was being sent >synchronously for the same reasons as in the Delivery Receipt discussion >above.</db> ></df> > >-Arvola > >-----Original Message----- >From: HUGHES,JIM (HP-Cupertino,ex1) <jim_hughes@hp.com> >To: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org> >Date: Monday, August 13, 2001 7:17 PM >Subject: RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessa >gingMethod in QualityOfServiceInfo > > >>Question: Does "reliable messaging" mean that the initial MSH (and maybe >>intermediate node MSHs) needs to consider this as a quality request and, if >>possible, pick the "most" reliable transport available? Or, is this just a >>protocol for the receiving MSH to send a confirming ACK back to the sending >>MSH? >> >>I think it's the latter, and thus there is no directive for intermediate >>node links to use the RM protocol to confirm among themselves that this >>message got through. From their perspective, the overall MSH Ack looks like >>a higher level function to them... and, in fact, it seems to me that having >>the intermediate links try to use their own version of RM between their >>endpoints really complicates the picture and maybe they should be >prohibited >>from trying to use RM since they aren't the start/end-points for the >overall >>message... IMO. >> >>jim >> >> >> >>> -----Original Message----- >>> From: Arvola Chan [mailto:arvola@tibco.com] >>> Sent: Sunday, August 12, 2001 9:30 PM >>> To: David Fischer; Burdett David >>> Cc: ebXML Messaging (E-mail) >>> Subject: Re: T2, Proposed solution for ... Re: SyncReply and >>> ReliableMessaging Method in QualityOfServiceInfo >>> >>> >>> David: >>> >>> My comments are bracketed by <ac> and </ac>. >>> >>> Cheers, >>> -Arvola >>> >>> ----- Original Message ----- >>> From: "David Fischer" <david@drummondgroup.com> >>> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David" >>> <david.burdett@commerceone.com> >>> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org> >>> Sent: Sunday, August 12, 2001 2:33 PM >>> Subject: RE: T2, Proposed solution for ... Re: SyncReply and >>> ReliableMessaging Method in QualityOfServiceInfo >>> >>> >>> > Arvola, >>> > >>> > What if I am sending to you and you are using an IM for >>> some reason, e.g. >>> no >>> > persistent connection? I might not even know and since I have no >>> agreement with >>> > that IM (my agreement is only with you), I cannot be responsible for >>> putting the >>> > CPAid in the Via -- there is no CPAid. What I can do is >>> fill in the Via >>> fields >>> > as much as I am able in case there is an IM I am not aware >>> of. This, IMO >>> will >>> > be a very common use case. >>> > >>> > This exact same situation would arise if you used multiple >>> MSHs where one >>> was a >>> > mailroom. >>> > >>> >>> <ac> >>> I must admit that your use case is a very valid one and I >>> have not made >>> provision for >>> it. >>> >>> Come to think of it, when I suggested that the sender MSH >>> should dictate if >>> all intermediaries >>> should use reliable message or not at all, it is not strictly >>> necessary for >>> the sender MSH to >>> know that intermediaries are involved, all it is choosing is between >>> reliable message with >>> intermediate Acks vs reliable messaging without intermediate Acks. >>> >>> As you have indicated earlier, "Even though the ends don't >>> need to know >>> about the IMs, >>> it is critical that the IMs realize their role." There, the >>> IMs should be >>> able to respect the >>> directive from the sender MSH to use intermediate Acks or not. >>> </ac> >>> >>> > You are correct, I need to be more clear. I believe the >>> sender MSH would >>> > construct the Via. This Via would pass to the first IM MSH >>> who would >>> construct >>> > a new Via (possibly very similar to the original) and pass >>> this new Via to >>> the >>> > next hop's MSH. >>> > >>> > NEW PROBLEM WITH MULTI-HOP? >>> > This brings up a good point. I (the From Party MSH) know >>> how to send to >>> you >>> > (the To Party MSH) because I can look up your connection >>> info in the CPA >>> > Database based upon a CPAid and a ChannelID. This info >>> might not reside >>> in the >>> > To PartyID element. If my message goes through an IM, how >>> does the IM >>> know >>> > where to send? I don't send to you, I send to my IM. If I >>> am using an >>> IM, does >>> > that mean any time I make an entry in my database I also >>> have to duplicate >>> that >>> > info to my IM (and they to each of their IMs etc.)? This >>> would not be >>> > acceptable. Maybe this connection info MUST reside in the >>> To PartyID? >>> This >>> > would not be a problem for single-hop. Maybe the Receiver >>> connection info >>> needs >>> > to be put in the Via? >>> > >>> >>> <ac> >>> I agree with you this is a problem. The intermediary needs to >>> be configured >>> with the >>> Endpoint and various characteristics for the To Party (or the >>> Endpoint for >>> yet another >>> intermediary who can route messages to the To Party directly >>> or indirectly >>> and its >>> characteristics). My understanding is that CPPs and CPAs >>> currently deal only >>> with >>> the point to point case. Therefore, there is no automated way >>> to configure >>> intermediaries >>> using CPAs. This is something the CPP/A TC will have to >>> address in its 2.0 >>> spec. >>> </ac> >>> >>> > Regards, >>> > >>> > David Fischer >>> > Drummond Group. >>> > >> >>------------------------------------------------------------------ >>To unsubscribe from this elist send a message with the single word >>"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org > > >------------------------------------------------------------------ >To unsubscribe from this elist send a message with the single word >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org > > >---------------------------------------------------------------- >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