[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FW: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo
On the contrary, it is attempting to do the intermediary function within the messaging service that is pushing function down into it that doesn't belong there. That's what an awful lot of the discussion has been about. We don't even have a definition of how two MSHs can work back to back without some function in between them. Regards, Marty "David Fischer" <david@drummondgroup.com> on 09/21/2001 07:09:18 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: <Chris.Ferris@Sun.COM>, "ebXML Msg" <ebxml-msg@lists.oasis-open.org> Subject: RE: FW: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo We can't put all these functions in the application. We are supposed to support Transport, Routing and Packaging. What you are suggesting is pushing Routing & Packaging into the application?!!! The application is just supposed to pass parameters and payload(s) to the MSH where the ebXML-MS headers are built, signed, encrypted and sent. The other end receives the message, parses the SOAP headers, performs Idempotency (RM), and then performs an IF: 1) if not the To Party then modify the packaging (Via, TraceHeaderList) and send to next-hop/end, 2) if the To Party, validate signatures/encryption and dispatch the payload(s) to the application based upon Service/Action. Look at figure 6-1. We do Header Parsing & Header Processing. We do RM. We also do Security Services. What I left out is Error Processing at each stage of the MSH. The IF in the above paragraph was introduced by multi-hop. If no multi-hop then do 2. Multi-hop does not appear in the figure (and let's NOT put it in). What you are suggesting reduces the MSH to just a message send & receive function. Why bother? You are suggesting a massive change in scope and functionality from the current specification. Regards, David Fischer Drummond Group. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Friday, September 21, 2001 5:40 PM To: David Fischer Cc: Chris.Ferris@Sun.COM; ebXML Msg Subject: RE: FW: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo A few 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 09/20/2001 05:45:07 PM To: Chris.Ferris@Sun.COM, ebXML Msg <ebxml-msg@lists.oasis-open.org> cc: Subject: RE: FW: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo Thanks Chris, very good points. <df>comments in-line</df> Regards, David Fischer Drummond Group. -----Original Message----- From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM] Sent: Thursday, September 20, 2001 11:50 AM To: ebXML Msg Subject: Re: FW: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo David Fischer wrote: > > As Chris pointed out, we need to carefully consider this. So, I am sending this > out again (slightly modified -- retryCount goes in Via). Does anyone see any > problems with this or does anyone have an alternative proposal? > > Regards, > > David Fischer > Drummond Group. > =============== > Proposal: > A retryCount attribute on Via. This parameter can only be set by the From Party > MSH and MUST start at zero. The first retry, retryCount is set to one, etc. How does this work if the sending MSH knows nothing of intermediaries? Are you suggesting that the Via element is now REQUIRED on all messages? <df>Yes, this is a problem, not only for retryCount but for all parameters in Via. I have asked this same question before, is Via always required? If we are doing RM at all, then Via is required in order to pass the ackRequested and reliableMessagingMethod parameters. I guess Via is REQUIRED for all RM messages -- regardless of retryCount. </df> > > Discussion: > Duplicate detection, as always, is detected by the To Party and From Party based > upon MessageId. Duplicate detection by the Intermediary is based upon MessageId > plus retryCount. How does an intermediary distinguish itself as such? This seems to preclude an MSH "module" that can be used anywhere as there is now a distinction between how an intermediary MSH node treats idempotency checking versus how an endpoint does so. MWS: Is it really a separate "module" or just an installation parameter. See next comment. MWS: If we agree that ALL intermediary function (even simple forwarding) is above the level of the MSH (i.e. an "appication"), we might make more forward progress/ <df>The IM must know that it is an IM in order to forward rather than process the payload. If the IM is not the From Party or the To Party then it must be an IM. This is not quite true for a mailroom situation (need to work on this -- something like MTA routing tables? or MX records?). </df> MWS: Again, if all the IM function is an application process, this is not a problem and an MSH does not have to care if it is in an intermediary or an end node. > > For example (see attached flow chart): > > Let's say there are three intermediaries (nodes B, C, D). A is the From and E > is the To. A sends a message with MessageId of 1 and retryCount of 0 (let's > call this ID 1.0). We will assume two failures occur during send -- the message > makes it to D but has problems sending to E. The Ack from C also fails going > back to B. Since A did not get a DR within retryInterval, it decides* to retry retryInterval applies to the RM retry. You are now stating that the DR is the RM artifact, not the Acknowledgment. What happens when no DR is requested/required? Does the sending MSH wait for the response message? <df>Chris, you are right, almost. There is a CPA to the first IM and a CPA with the end. There is a retryInterval in each which corresponds to that interval. However, what if the From Party does not know about any IMs? I think it would be wise for ends to always make retryInterval long and IMs to make retryInterval short. This is the kind of problem that will always exist with transparent IMs. This would be part of the initial system tuning process -- implementation detail. MWS: There was a suggestion a few days ago that eliminates the question of retry by the IM's. I will post something when I catch up with this blizzard of postings. retryInterval(end) > sum(retryInterval(IM)*retries) I am not saying DR is an RM artifact. You objected previously so I am no longer saying DR is part of RM. I changed the automatic retry to "decides*" to indicate that this happens by some unspecified means, not RM (read note at bottom) and not necessarily by retryInterval -- implementation decision. </df> > using ID 1.1. B will not see this as a duplicate and will pass it on. B will > also retry to C using ID 1.0. C will see ID 1.0 as a duplicate so it will not > send on but C will send an Ack back to B (who gets it). C will also receive ID > 1.1 and send it on since it is not a duplicate. Meanwhile D has finally made > the send to E and the DR and Ack have come back from E. D then receives ID 1.1 > from C and sends it on since it is not a duplicate. E receives ID 1.1 but since > E is the end, it sees ID 1.0 and ID 1.1 as duplicates (it only uses MessageId). > E sends an Ack to D for ID 1.1. E sees ID 1.1 as a duplicate so it does not > pass on to its application but it does send another DR back to A. A finally > receives two DRs, one for ID 1.0 and another for ID 1.1. So now A has to wait for the total possible number of DRs from E before it can stop worrying about the message. Why is A allowed to retry before it has any indication that there is a problem? The same retryInterval as might be used between A and B doesn't seem realistic to be reused between A and E as there may be a wide discrepancy between the expected response from B and the expected response from E. E may be only intermittently connected for any variety of reasons. <df>A will stop worrying about the message when it gets a DR (if requested). Why someone would retry is an implementation/user decision and probably not automated. We are leaving this decision criteria unspecified. </df> Thus, a separate parameter is needed to specify how long to wait for a DR (which is still optional as far as I'm concerned) or possibly the expected business response. As I understand, these are attributes that are presently expressed in the BPSS (timeToAcknowledgeReceipt and timeToPerform). MWS: I have previously mentioned unless the value of the timeout the MSH uses to decide that an acknowledgment isn't coming is made known (CPA?) and the start of the RetryInterval time is defined relative to other events, calculations with all these times are extremely iffy. I suspect that the timeout I am talking about is for receipt of an ACK, not a DR (which I believe is in the business level and in any case, optional). <df>Chris, we are leaving DR as optional and not part of RM -- at your request. There probably does not need to be a separate parameter because this may not be/probably won't be automated -- again at your request. Would you prefer an automated solution? </df> > > *The retry on lack of DR may be either manual or automatic -- implementation > dependant. > > ---------------------------------------------------------------------------- ------------------------ > Name: RM9.jpg > RM9.jpg Type: JPEG Image (image/jpeg) > Encoding: BASE64 ---------------------------------------------------------------- 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