Guys, Reading through this discussion on RM reinforces the idea that we haven't really addressed the issue from a layering point of vew. I remember many happy :-) hours spent at the whiteboard actively discussing this over the last 18 months. We need to really understand what is RM and what is a reliable business process. I offer this as a starting point: 1. Reliable messaging over a single hop ensures that a message (thought of as an opaque buffer) is delivered once and once only from a sender to a receiver. This corresponds to delivery from a sending MSH to a receiving MSH with no intermediaries in the ebXML context. This is similar to the MQSeries and HTTPR approach - somple point-to-point reliable delivery. Note that there is no talk about Acknowledgement receipts, NRR or whatever - this is simply getting a buffer from one point to another. 2. Sitting above this single hop is a distributed layer which handles the intermediaries. This is where the routing, LDAP (or whatever directories are needed), SOAP-RP is used. This layer relies on the lower, reliable delivery, single hop capabilities but inspects attributes of the message (mainly the ultimate recipient) to route the message. I believe from a performance point of view, the message must be as opaque as possible for routing to be as efficient as possible. Decrypting, encrypting and signatures should be kept out of this layer. 3. We then get to the end-points - the applications that send and receive the message. This is where the business process sits and I view things like NRR and anything to do with signatures as sitting here. Anything in the lower layers may alter the syntax of the message but it is only at the application level that the semantics (meaning) of the message can be altered. To answer David's question on MQSeries, it does not issue NRRs in the sense that has been discussed. There are programming exits that can be used to add those features, but the base product does not support it. It provides the services described in layers 1 and 2 above. Comments ? John XML Technology and Messaging, IBM UK Ltd, Hursley Park, Winchester, SO21 2JN Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271 Fax: +44 (0)1962 816898 Notes Id: John Ibbotson/UK/IBM email:
john_ibbotson@uk.ibm.com christopher ferris To:
ebxml-cppa@lists.oasis-open.org, <chris.ferris@eas
ebxml-msg@lists.oasis-open.org t.sun.com> cc: Subject: Re: reliable messaging - hop by hop 08/29/2001 02:54 PM Please respond to christopher ferris David, A NRR *may* not be meaningful in a legal sense unless it is signed by an authorized signer. The private key for the certificate that is authorized *may* not be available to the MSH for security reasons. This is why it is my strong belief that NRR is an application function. It does not seem reasonable to me to impose a requirement that the private keys that carry a weight of authority be made available to an MSH. This is not to say that an MSH does not have certificates that can be used to sign and/or encrypt message traffic. It is just that these certificates are potentially more vulnerable and hence they may only be accorded marginal trust (they may be used to sign and encrypt data such that message traffic confidentiality and integrity is preserved, but they cannot necessarily be used for authentication of anything other than the software that transmits the message). NRR is most assuredly an important aspect of electronic business message exchange. Of that there is no doubt. However, its function is somewhat orthogonal to a reliable messaging protocol. Cheers, Chris David Fischer wrote: > > I guess I take more of the end view. I need an Acknowledgement/Receipt from my > trading partner at the other end saying they received the message (not > application processing). Often, I need it to have a MIC and be signed by the > end for legal reasons (NRR). An Acknowledgement from some other intermediary > tells me nothing. How it gets there is of little or no consequence to me (Black > Box). If I don't get the Acknowledgement/Receipt then I need to be able to send > the exact message again and not have someone in the middle stop my retry > attempt. > > However, if the folks that handle the intermediaries tell me they need certain > mechanisms to make this transfer happen, then I am happy to oblige -- provided I > still get end-to-end NRR. > > Regards, > > David Fischer > Drummond Group. > >