[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and thelayering mishmash (was jumbled into: reliable messaging - hop by hop)
Dale, With regard to your statement: If there is a BPSS requirement for NRR, does that mean that the lower layers are to provide an implementation supporting NRR? Or is it an indication that the design of the business data structures in Requests and Responses support NRR functionality? Or is something else meant? CPPA has, I think, mainly been thinking that a BPSS requirement of NRR was a request that the underlying layers provide an implementation for NRR (an implementation that can be a basic or a more enriched implementation). I believe that the CPPA team was (implicitly or explicitly) thinking that NonRepudiation in the CPA is an explicit request for the MSH to provide NRR. The reason is that the NonRepudiation element is under DocExchange, which is the configuration information for specific MSH functionality. I am now beginning to understand that the thinking is not correct. From an implementation viewpoint, NRR may well be implemented by "the lower layers", but architecturally not by MSH. NRR may well be implemented by a middleware module acting on behalf of the application but architecturally, NRR is application function. If I am right, NonRepudiation should be moved to be a child of one of the elements related to the BPSS, probably to CollaborationRole or one of its child or grandchild elements. 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 ************************************************************************************* Dale Moberg <dmoberg@cyclonecommerce.com> on 08/31/2001 12:40:39 PM To: ebxml-cppa@lists.oasis-open.org, ebxml-msg@lists.oasis-open.org cc: Subject: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and the layering mishmash (was jumbled into: reliable messaging - hop by hop) David, I read one of your recent notes in which you present some interesting alternatives, and I would like to comment on these in the hopes of aligning BPSS, MSG, and CPPA on the NRR issues. David Burdett says, almost as an aside: "The other alternative would be to provide two variations of the Delivery Receipt, one which indicated that the To Party MSH had received and the second that the To Party Application had been notified of the message, but I don't really want to go there as it is definitely additional functionality." Despite your disclaimer, I think this is an area we should discuss so that we can align BPSS CPPA and MSG on NRR. (Maybe pretty soon I can write a sentence consisting entirely of acronyms.) I think that there _could_ be one DeliveryReceipt with an extension mechanism that could be used for all the additional conditions that tend to get tacked on to the DeliveryReceipt: One condition would be that the To Party Application was notified, another would be that the syntax had been checked, a third, that the syntax had been checked and the data typing had been checked and the values were in allowed ranges, and so on. We would in CPPA need an enumeration for the main different extensions, and a general "namespace supported" element to gesture at yet unthought of extensions (or whatever is the extension mechanism du jour). But strictly speaking, the functionality in these NRR extensions is beyond what a MSH needs to carry out its main jobs, even when that job includes supporting NRR. Let me briefly expand on this. NRR is something that rarely ends up getting uniquely characterized in terms of what needs to be _implemented_. We know what we want to obtain more or less, but can rarely agree upon what will always be sufficient to attain it. Because any processing exception that occurs after the MSH finishes its work may provide the To-Party a legal "way out," NRR always seems to be falling short of removing all wiggle room. I seriously doubt that we will remove all the wiggle room, and that there will always be some exceptional condition after receipt and after sending a DeliveryReceipt, that would result in a processing failure on the ReceivingParty side (bad syntax, semantics, and so on). To try to rule out each of these conditions by checking each of them before sending a DeliveryReceipt, leads to endlessly bloating DeliveryReceipt functionality, and finally a need to be in the position of being able to produce the Business Response before issuing a DeliveryReceipt. Clearly this drift leads to a layering mish-mash. In EDIINT we had very similar requirement flux. Eventually we just left an open extension mechanism for receipts, in terms of what can be added by industry groups. RosettaNet went through similar struggles in working out its private/public division. I personally think it would be good just to draw a line and say that "Receipt is obtained when the MSH has persisted the message payload off the wire," and let the MSH handle sending the DeliveryReceipt, signed and including an appropriate hash for the original message. Nevertheless, adding on an extension mechanism may appease others (especially in the BPSS side of things) enough that we can get all three main groups (BPSS, CPPA, and MSG) to agree that NRR has been implemented OK. The problem then will be in documenting this extension mechanism so that we can capture publication of and agreements upon extensions within CPPs and CPAs. We can then let the CPA adjudicate just how much "creep" into the application realm occurs (syntax check on payload, etc). So, David B's compromise might be a good way to proceed if the MSH is to provide NRR functionality. An alternative would be to follow Chris Ferris general preference to push all NRR all the way back up to the application. (At least I hope I am not misrepresenting Chris here.) I think, though, that would make the MSH far less interesting as a middleware component module. Pragmatically, NRR is not something that anything but new applications would be able to provide and even then, it might be difficult to ensure access to the data elements needed to compute the hash to indicate being in posession of the original message/payload/whatever. Moving on, David B. later says: "I actually think that the second one [involving an application notification assurance] is really an application level acknowledgement." I think we need to wonder why the application layer needs an acknowledgement, or why it needs to get involved in NRR issues. What is an application level acknowledgement as opposed to the application level response? Why should an application need to get involved in producing a receipt instead of its defined application level response? This seems to be forcing applications to get involved in detailed delivery related issues, when an application may only know only about its tasks to be performed and what do with its results (regardless of how the task got queued up to it...). I think that the BPSS group needs to explain why business applications should at all be in the business of worrying about generating acknowledgements or receipts. This is a source of layering conflict that is causing both CPPA and MSG difficulties in understanding how to finish their own tasks. If there is a BPSS requirement for NRR, does that mean that the lower layers are to provide an implementation supporting NRR? Or is it an indication that the design of the business data structures in Requests and Responses support NRR functionality? Or is something else meant? CPPA has, I think, mainly been thinking that a BPSS requirement of NRR was a request that the underlying layers provide an implementation for NRR (an implementation that can be a basic or a more enriched implementation). Is an application level acknowledgement an application response in addition to the real application business response or perhaps instead of a business response? I think that if a business layer process thinks it needs such an acknowledgement for its own purposes, then that function should be built into BPSS specifications as requirements concerning the detailed algorithms, hashes, etc in the structured data exchanged in requests and responses. In this case, NRR will be opaque to the MSH layer, and there will need to be no agreement on how NRR is to be achieved/implemented (so DeliveryChannel characteristics do not need to be assessed to see whether NRR is supported on a channel.) This may be consistent with the Chris Ferris option discussed above; I personally would like to see a POC demonstrating this approach working interoperably before allowing it in an approved spec. Dale Moberg ---------------------------------------------------------------- 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