[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues
David, Please see below. Cheers, Chris David Fischer wrote: > > Chris, > > Wow, what a proposal! I *think* your way would work but it is such a > substantial change to the way the spec reads now that I would vote NO just on > those grounds. Version 1.1 is supposed to be only bug fixes. Your proposal > also does not address (intentionally) what I perceive as a requirement -- > end-to-end MSH level receipts. We don't want to have to go all the way to the > application to determine whether or not to retry. Each developer would have to > write this code into EVERY APPLICATION. No, we can't do things that way. This > is Transport Layer functionality. Let us not confuse "application layer" with application here. By "application layer" I mean a level of software that is above the MSH in the stack. If you have an eBusiness Server, the MSH is only a component of that. The determination can be left to that level since we are concerned not with defining a specification for an implementation of an eBusiness Server, but of a wire protocol and required behavior of an abstract MSH. > > If you don't want to call Delivery Receipts a part of Reliable Messaging, I > don't really care. I don't want to quibble over semantics. Whatever the > process ends up being called, MSH level Delivery Receipts are essential and the > ability to retry on lack of a Delivery Receipt is just as important. This was > all in the specification prior to multi-hop and it needs to stay there. DB's > proposals do just that and I support them. As I have said before, we don't need to support end-to-end retries if we have (as I know we all understood) a consistent application of RM semantics at all MSH nodes involved in a message exchange. We never discussed end-to-end retries above and beyond p2p retries in TR&P until you raised this issue post 1.0 publication. If anything is v2.0, then I would think that end-to-end retries over and above p2p RM is. > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of > christopher ferris > Sent: Friday, September 07, 2001 1:34 PM > To: ebXML Messaging (E-mail) > Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues > > My turn;-) > > Please see my comments below. > > Cheers, > > Chris > > "Burdett, David" wrote: > > > > Arvola > > > > See comments in line. > > > > David > > > > -----Original Message----- > > From: Arvola Chan [mailto:arvola@tibco.com] > > Sent: Thursday, September 06, 2001 4:47 PM > > To: ebXML Messaging (E-mail) > > Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues > > > > David and David: > > > > I don't have any major objection to the proposed changes. > > My comments are in tandem with David Fischer's bracketed > > by <ac> and </ac>. > > > > Regards, > > -Arvola > > > > -----Original Message----- > > From: David Fischer <david@drummondgroup.com> > > To: Burdett, David <david.burdett@commerceone.com>; ebXML Messaging (E-mail) > > <ebxml-msg@lists.oasis-open.org> > > Date: Thursday, September 06, 2001 3:19 PM > > Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues > > > > David, > > > > Looks pretty good. > > <df>Comments inline</df> > > > > Regards, > > > > David. > > > > -----Original Message----- > > From: Burdett, David [mailto:david.burdett@commerceone.com] > > Sent: Thursday, September 06, 2001 1:44 PM > > To: ebXML Messaging (E-mail) > > Subject: T2 PLEAE READ - Suggested solution to RM Issues > > > > Folks > > > > If you do not respond to this email then, as chair of the T2 effort, I AM > > GOING TO ASSUME YOUR SUPPORT. So please read at least the first part of this > > email which explains why I am doing this ... > > > > There has been a LOT of discussion about Reliable Messaging on the list. I > > also sense that different people's views are gradually aligning. However to > > move forward we HAVE to come up with constructive suggestions. I first did > > this a nearly a month ago see ... > > > > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00125.html > > > > Although there were a lot of replies to this email few of them were about > > the actual suggestions I made. Those that were received (Arvola Chan & David > > Fischer) were generally in agreement although both suggested worthwhile > > improvements. So in order to focus on the solution I have restated the > > approach in my earlier email below with a few tweaks to reflect more recent > > discussions. > > > > What I think will be really constructive is if we use this suggested > > solution as the basis for discussion so that we can refine it and hopefully > > finalize it in the F2F on October 3-5. Once we get agreement we can then > > start making changes. > > > > Furthermore, AS CHAIR OF THE T2 EFFORT I AM GOING TO ASSUME THAT NO COMMENT > > MEANS ACCEPTANCE. I don't like doing this but unless we start talking about > > solutions rather than problems we will not make progress. > > > > Does this makes sense? > > > > Finally, I've missed some of the detail of the discussions in order to make > > the suggested solution (fairly) brief. This does not mean they are not > > included ... they definitely will need to be ... and if they are important, > > I am sure you will make your views known ;) > > > > Best wishes to everyone. > > > > David > > SUGGESTED CHANGES TO SOLVE RM ISSUES > > > > Change 1 > > -------- > > Summary: Rename the Via element as "Next Actor Data" or similar. > > > > Rationale: There can always be "intermediaries" in a message transfer even > > if you are going point-to-point. For example consider the two example > > message flows that I recently posted that cover the following use cases: > > 1. A genuine intermediary who is a third party that is running a MSH and > > forwards messages to the final destination. > > 2. A Party which has a MSH that acts as a "mailroom" that forwards the > > message internally using ebXML RM to another MSH that then forwards it to > > the application. The "mailroom" MSH ia an intermediary. Chris Ferris > > provided an example of this use case at > > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00412.html > > > > I think we need to support both use cases. By renaming the Via element as > > "Next Actor Data". We are simply saying that the data contained within the > > element is for the Next Actor **only** and does not need to be forwarded. > > The Next Actor recreates the data as they need to if they are forwarding the > > message. If we think of the data in the Via as being for the "Next Actor" > > then we are also more closely aligned with SOAP. It also removes the problem > > of treating intermediaries as "something special" and allows an internal MSH > > to forward the message to another MSH without the original sender needing to > > know and without having to re-create the complete message. > > > > <df>I agree with all your rationale. My only question is backward > > compatibility > > issues with 1.0 implementations due to the name changes.</df> > > <cf> > I agree that the name change seems arbitrary and should only be taken > after careful consideration of any backwards-compatibility issues. > </cf> > > > > > <ac> > > I am ambivalent about the name change. Clarification of the intent of the > > element and its usage rule is sufficient for me. > > </ac> > > <db>We might need to vote on this.</db> > > <cf> > My take is that lumping *all* of the stuff designated for the "next" actor > would be a mistake. We should be leveraging SOAP as it is intended. IMO, a > SOAP "block" or header should have a specific purpose. More comments on > this below. > </cf> > > > > > Change 2 > > -------- > > Summary: Data in the Next Actor Data (Via) element is for the Next Actor > > only > > > > Rationale: What Change 1 means is that we must carefully review the existing > > elements in the header and check to see whether they are needed by the > > ultimate destination/endpoint or the next actor. I think that this will > > require the following changes: > > 1. CPAId. The CPAId in the Message Header identifies parameters that apply > > "end-to-end", e.g. business process level stuff, whereas the CPAId in the > > NAD/Via element applies to the transport over a single hop, e.g. transport > > level stuff. I realise this will require changes to the CPP/A ... and > > probably more discussion. > > > > <df>Agreed. This may not require any CPA change at all since, as Marty put > > it, > > multi-hop is just a set of binary collaborations. There is a CPA with the > > end > > and a CPA with the next hop. This is perfect. What is the value if there > > is no > > IM? Needs to be optional or allowed to be empty.</df> > > > > <ac> > > I agree with David Fischer. > > </ac> > > <cf> > As I believe David B has pointed out, the CPAId in the Via element is > currently optional in the v1.0 spec. > </cf> > > > > > 2. Acknowledgment Element. This should be part of the NAD/Via element as > > acknowledgments are between two MSHs and are not propogated to the original > > sending party. > > > > <df>No, if we move Acknowledgement to Via then we remove it from the > > Signature. > > This is OK if we don't want signed Acknowledgements. > > > > <ac> > > I suppose it is possible that the CPA between two intermediate MSH > > calls for non repudiation of receipt in which case the Acknowledgement > > would have to be signed. I vote for keeping the Acknowledgement > > element outside of the Via element. > > </ac> > > <db>I agree with this also and have withdrawn this suggested change.</db> > > <cf> > Agree that Acknowledgment, which is already targetted at the "next" actor > should remain as a separate SOAP header block as per the v1.0 spec. > </cf> > > > > > If we are going to make this massive a change, then let's go all the way and > > move TraceHeaderList to Via and simplify the ds:Signature Transform. > > TraceHeaderList must be modified by each hop and then passed to the next. > > TraceHeaderList is intended for the next hop so it also should be part of > > Via. > > > > <ac> > > I agree that it makes logical sense to move the TraceHeaderList > > under the Via/NAD element. > > </ac> > > <db>I've a change of view here in that we should not move it unless there is > > a real reason. We just need to make it clear what the "next" and "to" actors > > need to do with each SOAP extension</db> > > </df> > > <cf> > The TraceHeader list is already targetted at the 'next' actor. I see no > reason whatsoever to relocate it. > </cf> > > > > > Change 3 > > -------- > > Summary: Make Next Actor Data (was Via) a required element. > > > > Rationale: There are two reasons for this: > > 1. The current Via element contains data that is REQUIRED for > > point-to-point, e.g. ReliableMessagingMethod. > > <cf> > If you have a CPA, whether real or imagined, and no intermediary then > ReliableMessagingMethod is not needed in the message itself. The two nodes > already have an understanding as to how they are effecting RM as per their > agreement. Thus, it is not REQUIRED for point-to-point RM at all. > </cf> > > > 2. There are two levels of reliability, that need to be covered: > > point-to-point (P2P) as well as end-to-end (E2E). > > <cf> > The fact that the parties agree to exchange receipts is orthogonal > to RM. The fact that the RM protocol that is defined by the spec > uses Acknowledgments is mere coincidence. We could have employed > other mechanisms to acheive reliability. If it is desired that > there be a formal expression of the equivalent of "I expect an > acknowledgement" in the SOAP envelope, targetted at the "next" > actor with a mustUnderstand=1, I suppose I have no problem with > that. I would prefer that it be a standalone SOAP header and not > merely lumped in with a bunch of other stuff. > </cf> > > > > > Currently Via is optional. If we are doing point-to-point, then you would > > have to have ReliableMessagingMethod duplicated at the header level in order > > to solve the problem. This does not make sense. Making NAD required solves > > this problem. > > <cf> > See above, I disagree with the assertion that ReliableMessagingMethod > is required in the MessageHeader. > </cf> > > > > > The layering problem of P2P vs E2E is similar to the problem that TCP/IP > > solves as was clearly stated by Dan Weinreb at > > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00225.html. Marty > > Sachs, David Fischer and others have also repeatedly said that unless you > > have end-to-end acknowledgement then there is no certainty. I think we need > > to recognize that there can always be two levels and therefore need to > > recognize both these levels in the header. > > > > Now TCP/IP does this as two SEPARATE layers. The current spec puts both > > layers in one spec with one header. I don't think we NEED to radically > > change the spec in this area but would like peoples views. > > > > <df>Agreed. What is the value of Via CPAId if there is no IM?</df> > > > > <ac> > > The CPAId under the Via element is optional according to the XSD. > > If the QOS is BestEffort and no intermediary MSH is involved, there > > is no need for the Via/NAD element. I think it can remain optional as > > long as we can clearly articulate the circumstances under which it must > > be present. > > </ac> > > <db>Not sure this works. There are additional attributes in the NAD (Via) > > element that are currently required such as syncReply. Arvola. Can you ckeck > > the spec and determine which is optional which is required and specify what > > the default semantic should be for each of these elements/attributes if the > > NAD/Via is not present.</db> > > > > Change 4 > > -------- > > Summary: Make the return of a Delivery Receipt required if > > deliverySemantics=OnceAndOnlyOnce > > > > <df>Agreed</df> > > > > <ac> > > I agree. Even if the incoming reliable message does not have > > the DeliveryReceiptRequested attribute set, the receiver MSH > > should still return a DeliveryReceipt. > > </ac> > > <db>I agree but is should be unsigned. This is the default value. See > > below.</db> > > <cf> > I disagree! As I have repeatedly stated, the delivery receipt is > not a function of RM. Do not tie the two together. If you want a > deliveryReceipt, then ask for it using the existing mechanism > (deliveryReceiptRequested). If you want that whenever you send a > message with OnceAndOnlyOnce you ask for a deliveryReceipt, be my guest. > > Please, do not make this a requirement. > </cf> > > > > > Change 5 > > -------- > > Summary: Remove "None" as an option for deliveryReceiptRequested and make > > deliveryReceiptRequested=false the default. > > > > Rationale: As the return of a Delivery Receipt is the only sure way that you > > know a message was delivered suggests that it will be a simpler solution if > > we make this always the case. Therefore we can make the return of a delivery > > required if the deliverySemantics are OnceAndOnlyOnce. However you still > > need to know if the receipt must be signed. > > > > <df>Agree with removing "None" but would prefer to leave as "Signed | > > Unsigned" > > for backward compatibility. Default is "Unsigned".</df> > > > > <ac> > > I agree with David Fischer. > > </ac> > > <db>So did I!</db> > > <cf> > Again, as I disagree with making a DR REQUIRED, I see no real value > add in changing "None" to "false" unless the DR is ALWAYS signed > in which case making the attribute an XSD boolean would make sense. > </cf> > > > > > Change 6 > > -------- > > Summary: Make the return of an Acknowledgment element in a message required > > if the ebXML RM protocol is being used > > > > <df>Agreed, but isn't this already true?</df> > > > > <ac> > > I agree with David Burdett. The current spec does not required the > > Acknowledgement element to be present in an Acknowledgement > > message. > > </ac> > > <db>I agree with you and me ;)</db> > > <cf> > Huh? If the issue is that section 10.3.3 is less than clear as to whether > an "Acknowledgment message" MUST have an Acknowledgment element, then > clearly, that is an editorial issue that should be addressed. Seems > to me that lines 1814/1815 should be changed to read: > > At a minimum, it MUST contain a MessageData element with a > RefToMessageId that is set to the value of the MessageId of > the message being acknowledged along with an Acknowledgment > element as described in section 8.6. > </cf> > > > > > Change 7 > > -------- > > Summary: Remove "None" as an option for ackRequested and make > > ackRequested=false the default. > > > > Rationale: The rationale for doing this is similar to changes 4 and 5. It > > simply gives the rule that if you are doing ebXML RM then you must include > > an Acknowledgment element in the response. The response can be synchronous > > or asynchronous (see change 11 below). > > > > <df>Agree with removing "None" but would prefer to leave as "Signed | > > Unsigned" > > for backward compatibility. Default is "Unsigned". (same as Change 5)</df> > > > > <ac> > > I agree with David Fischer. > > </ac> > > <cf> > Actually, consistent with the proposal I put forth above, adding a > SOAP header block requesting an Acknowledgment would be a bit more > coherent IMO. > > e.g. > > <SOAP:Envelope xmlns:SOAP="..."> > <SOAP:Header> > <eb:MessageHeader xmlns="...">...</eb:MessageHeader> > <eb:AckRequested xmlns:eb="..." > SOAP:actor="http://.../next" > SOAP:mustUnderstand="1" > eb:signed="true|false"/> > </SOAP:Header> > <SOAP:Body> > <eb:Manifest xmlns:eb="..">...</eb:Manifest> > </SOAP:Body> > </SOAP:Envelope> > > This approach is more consistent with SOAP and it eliminates the > need to worry about ReliableMessagingMethod. It also provides for > the Acknowledgment to be used for a foriegn specification for a reliable > protocol that also used acknowledgments. For that matter, we could > consider the AckRequested and Acknowledgment elements to be a > SOAP module that is useful in and of itself. It could be essentially > a self contained module with its own set of processing semantics > specified, etc. IMO, this is a far cleaner and more modular approach. > </cf> > > > > > Change 8 > > -------- > > Summary: Include automated retry by the original sender (From Party) if no > > Delivery Receipt is returned > > > > <df>Agreed</df> > > > > <ac> > > Do we need to give some guideline on the selection of retry interval > > for hop-to-hop vs retry interval for end-to-end? I think the former > > interval > > should be shorter than the latter. > > </ac> > > <db>Agree this would need to be included in the revised spec.</db> > > <cf> > I disagree for the reasons I've repeatedly cited. Absence of a received > DR does NOT mean that the message hasn't been delivered. It only means that > the sending party hasn't received a DR. > > I would counter-propose the following: > > - REQUIRE that ALL MSH nodes that receive a message with OnceAndOnlyOnce > deliverySemantics SHALL comply with the reliable messaging semantics > as defined in section 10. Further specify that any MSH node that > acts as an intermediary SHALL forward the message onto the next MSH > node using reliable messaging semantics as defined in section 10. > > - REQUIRE that a DFN SHALL be sent to the From Party (section 10.4) > as requested by Marty if a message cannot be delivered. > > - Clarify what "cannot be delivered", in section 10.4, means: > A message that is sent with deliverySemantics of OnceAndOnlyOnce > for which the MSH, after exhausting the specified number of > retries, separated by the specified retryInterval, has either > been unable to send (e.g. unable to establish a network connection > with the designated MSH node to which the message is to be delivered) > or for which no "Acknowledgment message" has been received. > > - REQUIRE that a DR be delivered reliably (OnceAndOnlyOnce) if requested > > - add a MSH "parameter" for DRTurnAroundTime or something like that > which the sending MSH uses to wait for a DR > > - REQUIRE that the From Party's origin MSH notify the "From Party" > if the DRTurnAroundTime expires before receiving a DR > > - let the "application layer" of software make the determination as > to whether or not it wants to resend the message, possibly using > an alternate delivery channel. > > Please do keep in mind that a NRR/DR SHOULD be supported even if > the deliverySemantics are BestEffort IMO. Let us not confuse these > mechanisms. > > Adding in the complexity of having to deal with intermediaries > re-forwarding/processing messages for which no DR has been > received would be a mistake IMO. It raises the bar on the complexity > of an MSH considerably, especially for processing intermediaries > as I have repeatedly pointed out. > > If we stick with a store and forward, all nodes must adopt, protocol > then if a message does not go through, there are WAY bigger problems > than might be addressed by resending the message in any event. > > </cf> > > > > > Change 9 > > -------- > > Summary: Include a "MessageRetryCount" in the NAD (was Via) element in the > > Message Header > > > > Rationale: There is a need for automated retry by the original sender (From > > party) if a Delivery Receipt is not received. However, the original sender > > wants to send the **identical** message yet not have it treated as a > > duplicate and by any intermediate MSH that has previously received it. To > > solve this problem you can add a "MessageRetryCount" to the NAD which > > indicates to the MSH that even though they have received the message before > > they must still forward it.In this case even if the resend is received first > > and the original appears some time later, the ToParty will be able to > > recognize that the message has already been processed by comparing MessagIds > > only and therefore the original should be ignored. This logic needs to be > > included in section 10 and will need to include another level of > > RetryCounts/RetryIntervals to work at the end-to-end rather than the > > point-to-point level. > > > > <df>Agree on MessageRetryCount. No need for another level of > > Retries/RetryInterval since it already exists -- there is one set in the > > end-to-end CPA (MessageHeader CPAId) and another in the Sender-FirstHop CPA > > (Via > > CPAId).</df> > > > > <ac> > > I agree with David Fischer. > > </ac> > > <cf> > As I said above, this raises the bar on complexity. You cannot use the > same retries/retryInterval as for single-hop for starters. Consider a > long chain of intermediaries which may have the ultimate recipient receiving > the message after a significant passage of time for which the sending > node wants to simply know when to stop resending (or trying to resend) > the messsage to the first intermediate node. > </cf> > > > > Change 11 > > --------- > > Summary: Include syncReply at both the Message Header and the NAD/Via > > elements > > > > The To Party needs to know whether the From Party wants the Delivery Receipt > > and Business Payload assembled into one message.The next MSH needs to know > > whether to send back an Acknowledgment synchronously or wait for the > > Business Payload before sending it. The Delivery Receipt and Business > > Payload can be sent asynchronously and the Acknowledgment sent synchronously > > and vice versa as they are independent of each other. > > > > As you can't easily cover both requirements in a single element, they need > > to be included separately in the header and in the NAD(Via). > > > > <df>Agreed</df> > > > > <ac> > > I agree in general. > > > > The semantics of syncReply need to be aligned with the CPP/A spec. > > The notions of signalsOnly, signalsAndResponse, and responseOnly > > in the CPP/A spec need to be expanded to cover Acknowledgements > > and DeliveryReceipt. Signals are application level messages according > > to the BPSS spec. > > </ac> > > <db>I agree that the MS and CPPA specs need to be aligned.</db> > > > > Change 12 > > --------- > > Summary: Clearly explain the relationship between applications, MSHs and > > partys and the need for notification. > > > > Rationale: Marty Sachs has clearly demonstrated the absolute need to be > > clear about stating the requirement that the From Party "knows" that the > > message has been delivered. We need to clarify the spec to make sure that > > this is clear. > > > > <df>Agreed.</df> > > > > <ac> > > I agree. > > > > I also like to propose a Change 13. If ackRequested is implied whenever > > deliverySemantics is onceAndOnlyOnce and reliableMessagingMethod > > is ebXML, then there is no real need for an ackRequested attribute > > (under the Via element). > > <db>Disagree. You need to indicate whether it is signed or unsigned. With > > the changes above, if it is absent, then it implies that it is > > unsigned.</db> > > <cf> > Please see my proposal above. > </cf> > > > > > If end-to-end reliable messaging does not imply hop-to-hop reliable > > messaging, then we should clearly state that in the spec. > > <db>Yes and no. I think that reliability works at two levels the hop and > > point-to-point. They can actually work independently of each other as Dan > > Weinreb has described.</db> > > > > Also, I believe in earlier discussions we have said that a Delivery > > Failure Notification message from an intermediate MSH to the > > sending MSH should be sent using reliable messaging. Such a > > statement and the rationale for doing so should be incorporated into > > section 10 as well. > > <db>Agreed. Does the text contained in the email to Marty at > > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00365.html meet the > > need? It proposes a revision to section 10.4</db> > > </ac> > > <cf> > Agreed. However, I think that both DR and DFN should be delivered > reliably. No DR for a DR though. > </cf> > > > > > Product Manager, xCBL, XML Standards > > Solution Strategy, Commerce One > > 4400 Rosewood Drive, Pleasanton, CA 94588, USA > > Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704 > > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com > > > > ---------------------------------------------------------------- > > 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