[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: You asked me to check the contents of the Via element to see if the Via element can be omitted when QOS is BestEffort for the single-hop case: ><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> Your proposed change #11 calls for having syncReply both under MessageHeader and Via, so for the single-hop BestEffort case, the information can be obtained from the MessageHeader. The elements and attributes under Via are: - CPAId -- not needed for single-hop - Service -- not needed for single-hop - Action -- not needed for single-hop - id -- not needed when Via is not present - version -- not needed when Via is not present - actor -- not needed when Via is not present - syncReply -- can be obtained from MessageHeader - reliableMessagingMethod - not needed when QOS is BestEffort - ackRequested -- not needed when QOS is BestEffort Therefore, my conclusion remains that the Via element is not needed when QOS is BestEffort and no intermediary is involved. Regards, -Arvola -----Original Message----- From: Burdett, David <david.burdett@commerceone.com> To: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org> Cc: 'Arvola Chan' <arvola@tibco.com> Date: Thursday, September 06, 2001 5:23 PM Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues >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> > ><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> > >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> > >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> > >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> > >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. >2. There are two levels of reliability, that need to be covered: >point-to-point (P2P) as well as end-to-end (E2E). > >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. > >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> > >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> > >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> > >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> > >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> > >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> > >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> > >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> > > >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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC