[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues
Hi Marty You said below ... >>>In any case, anything that starts to look like a multiparty CPA is well beyond the scope of Ver. 1.1.<<< Are you talking about version 1.1 of the CPPA spec. If so fine. If you mean the MS spec then I disagree as we should not make the MS spec **dependent** on the CPPA spec - this has been agreed to a long time ago. There was also agreement in earlier emails that we should make this separation clerarer in the current spec. In addition the current spec has CPAId in both the Via and the Message Header so we need to define what the semantics mean. This and a few other comments inline. Regards David -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Friday, September 07, 2001 12:00 AM To: Burdett, David Cc: ebXML Messaging (E-mail) Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues A few comments in line. 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 **************************************************************************** ********* "Burdett, David" <david.burdett@commerceone.com> on 09/06/2001 02:44:13 PM To: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org> cc: 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? MWS: This makes a lot of sense because it will keep listserver traffic down a bit. 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 MWS: Unless I misunderstand something, (2) is the normal case since this kind of intermediary is the basic MSH function. It isn't obvious why a NAD (via) element would be needed for this case if there are no other intermediaries. One reason might be simply to simplify processing by having the via there at all times as you indicate in (3) below. <db>Yes, 2 is the normal case. However if delivery semantics is 1&o1 and there is no NAD (via) element then it implies the the ebXML RM method is being used. This might not be what you want to do as you are using MQ Series instead. I am however also coming to the conclusion that making Via mandatory is not needed if you are using BestEffort.</db> 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. 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. MWS: We need to discuss this Oct. 3. Having CPAId in both places implies to me that there are two different CPAs, one between the From party and To party, and one between the From party and the first intermediary. <db>I agree. I think this is very necessary.</db> It isn't clear to me that this by itself will require any changes to the CPP/CPA though taking all the discussions as a whole, it is likely that there will be changes to the CPP/CPA for one thing or another. <db>I also agree.</db> In any case, anything that starts to look like a multiparty CPA is well beyond the scope of Ver. 1.1. <db>Are you talking about version 1.1 of the CPPA spec. If so fine. If you mean the MS spec then I disagree as we should not make the MS spec **dependent** on the CPPA spec - this has been agreed to a long time ago and there was agreement in earlier emails that we should make this separation clerarer in the current spec. In addition the current spec has CPAId in both the Via and the Message Header so we need to define what the semantics mean.</db> 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. 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. Change 4 -------- Summary: Make the return of a Delivery Receipt required if deliverySemantics=OnceAndOnlyOnce 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. Change 6 -------- Summary: Make the return of an Acknowledgment element in a message required if the ebXML RM protocol is being used 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). Change 8 -------- Summary: Include automated retry by the original sender (From Party) if no Delivery Receipt is returned 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. 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). 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. MWS: I agree :-) 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC