[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo
Marty's answer is precisely why we had difficulties in introducing multi-hop RM in MSS V1. I agree with Marty's general observation of the purpose of RM, though I would word it as "getting confirmation of message delivery between the FromParty MSH and the ToParty MSH" -- pointedly, whether there are intermediate MSH nodes (running RM or not) or static on the wire is not material, as both scenarios could introduce failure. This is a MSH-level session protocol, if you will, that just involves the two MSH end points. Maybe you get more "reliability" if an intermediate MSH node pair use MQseries, but I think it really confuses the issue when you allow the presence of intermediate nodes to affect the basic RM algorithm. I think that a node's use of RM should be quite distinct from the (higher layer?) RM between the endpoint MSHs. jim > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Tuesday, August 07, 2001 9:42 AM > To: David Fischer > Cc: ebxml-msg@lists.oasis-open.org > Subject: RE: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > > > In my mind, the only meaningful purpose of reliable messaging > is to get a > message from the From Party's application to the To Party's > application > once and only once. Everything else is details of how to do > it. Further, > it cannot be guaranteed that there will never be a failure to > deliver a > message, then the From Party's application is owned a > guaranteed delivery > failure notification. Multihop complicates the definition and > implementations but it does not change the purpose. > > 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/07/2001 11:22:54 AM > > To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org > cc: > Subject: RE: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > > > Marty, > > The purpose of Acks is for hop-to-hop RM only. The way it is > set up now, > once > the message passes a hop which is not able to handle RM or > doesn't need RM > (like > MQseries) then none of the remaining hops will do RM since > there is no way > to > reset AckRequested once it passes the unreliable hop. > > If intermediate-hop RM is not useful then why have Acks at > all? End-to-end > RM > can be done strictly with DeliveryReceipts ;-). But, I am > not suggesting > getting rid of intermediate Acks, only getting rid of the AckRequested > attribute > in Via. We need intermediate Acks and we need > intermediate-hop RM. We > don't > need end-to-end Acks because we already have DeliveryReceipt > but they need > to > act the same for RM. By removing AckRequested and using only > DeliveryReceiptRequested, the integrity of the RM request is > maintained > throughout the path. Any hop which can do RM then will > (unless overridden > by a > local CPA). > > David Fischer > Drummond Group > > BTW, let's change Acknowledgment (or Acknowledgement) to Ack. > I liked that > idea! > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Tuesday, August 07, 2001 9:26 AM > To: ebxml-msg@lists.oasis-open.org > Cc: "Chris Ferris" > Subject: RE: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > > > > ************************************************************** > ****************** > > ***** > > 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 > ************************************************************** > ****************** > > ***** > ---------------------- Forwarded by Martin W Sachs/Watson/IBM > on 08/07/2001 > 10:25 AM --------------------------- > > Martin W Sachs > 08/07/2001 10:24 AM > > To: David Fischer <david@drummondgroup.com> > cc: > From: Martin W Sachs/Watson/IBM@IBMUS > Subject: RE: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo (Document link: Martin W. Sachs) > > Again, be careful with the ACKS. > > If the To and From parties are separated from each other by > intermediaries > A, B, C in series, and B can't do reliable messaging: > > a) It doesn't matter that B can't do reliable messaging if > the reliable > messaging protocol is betwen the To and From parties' MSHs, > which is what > it should be. The job of hops A, B, and C is simply to move > the message > along. I suppose that the A-B and B-C hops could do their > own reliable > messaging under the covers but, as I said in the earlier posting, if C > loses the message before forwarding it to the To party, then > the fact that > A-B and B-C are doing reliable messaging is of no value. The > message still > won't get to the To party. > > b) Aside from that, if hop B-C is generally unreliable, > reliable messaging > can still be done between the To and From parties. However, > the To party's > MSH may have a higher than normal frequency of retries > because of the low > quality of hop B. > > 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/07/2001 09:42:09 AM > > To: christopher ferris <chris.ferris@east.sun.com> > cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > > > How do you set SyncReply on a message-by-message basis? If I > understand > you > correctly, syncReply MUST apply to ALL transfers between two > parties or to > None -- must always be the same. I think we may want a little more > flexibility. > We allow this flexibility in multi-hop, why not in single-hop? > > In EDIINT, syncReply was always default to True and we > occasionally would > change > to False for very large files -- allowing the connection to > close rather > than > wait (potentially hours) for a very large file to be > decrypted or the MIC > to be > generated for a NRR. (Instead of syncReply, EDIINT calls > this parameter > Receipt-Delivery-Option). IMO, we need to allow for the unforeseen. > > In the case of ReliableMessagingMethod, I'm not even sure > what this does or > why > we need it at all. What does a value of "Transport" mean -- the spec > doesn't > say? I assume it means just send the message and don't worry about RM > since > this hop can't handle it? I think this will never be used > but David seemed > to > think it was needed and I don't have any heartburn with that. > Since I this > sits > right next to SyncReply in the Ack, I included it in > parameters which need > to be > allowed without an Ack. Either way is fine with me. > > David. > > -----Original Message----- > From: christopher ferris [mailto:chris.ferris@east.sun.com] > Sent: Tuesday, August 07, 2001 5:58 AM > To: David Fischer > Cc: ebXML Msg > Subject: Re: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > > David, > > Where does this requirement come from? In the case of > syncReply, the CPA is what determines this. In the absence > of a CPA, then a virtual CPA applies. > > Cheers, > > Chris > > David Fischer wrote: > > > > There should be nothing in the Via which is not also in > other headers. > Via > > should only be used for multi-hop intermediaries. In the case of > SyncReply, > > there is no single-hop way of requesting SyncReply=true. > > > > Attributes SyncReply and ReliableMessagingMethod should also be in > > QualityOfServiceInfo. They should retain their current defaults. > > > > 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 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 unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC