All, Consider the following. One very valid, and I believe common use case for intermediaries involves no third party at all. Rather, an enterprise with a dual firewall may employ routing intermediaries for the purpose of allowing its business partners to send messages that are securely routed through to the internal network where the actual processing of the messages takes place. eg. MSH MSH MSH App-->A----> ----------> -->B--> -->B1-->App A's intranet internet DMZ B's intranet firewall firewall firewall In this scenario, the single-hop RM between MSHes A and B is all that enterprise A knows about, and quite frankly, anything that goes on inside B's enterprise is none of A's business. The CPA between A and B designates the endpoint URL for the B MSH as the endpoint to which messages from A shall be delivered. From A's perspective, a message sent to and acknowledged by the B MSH (using the ebMS defined RM protocol) is a reliably delivered message. In the above scenario, the B MSH persists the message, sends the ack to the A MSH and then routes the message to B1 (also reliably but quite possibly, via an alternate protocol such as MQ) which in turn dispatches the message to the App inside B's enterprise. In this, and any other scenario involving RM, the receiving node accepts the responsibility for delivering the message, to its next destination, reliably. The ebMS1.0 spec hints at this, but unfortunately, doesn't express this fact as clearly as it should. IMO, the spec should clearly say something such as the following in addition to what it already says in sections 10.1.1 and 10.2.1: Any MSH that receives a message that has a //QualityOfService[@deliverySemantics = OnceAndOnlyOnce ] MUST provide for the reliable delivery of the message to the application software that has been designated to process the message. Application software that provides message routing functionality for an MSH MUST preserve and provide for the QualityOfService/@deliverySemantics of ALL messages when forwarding the message to its next destination MSH. This is in keeping with our agreement in various f2f meetings that message routing is an application function, not a function of the MSH itself. As to NRR, in the scenario described above, the B MSH node may not have access to the requisite private keys that A has agreed to TRUST because of the potential vulnerability of any component that is directly accessible from the internet. In this scenario, it may only be an agent INSIDE the dual firewall that can have access to the private key required to sign a NRR response message that party A will trust. Security is all about trust. A certificate that is used by B for SSL connections between A and B above can only be marginally trusted. All it asserts is that the connection from machine A was accepted by machine B. It provides only limited authentication assurance. If party A wants something it can take to court, then it should demand that the certificate's private keys be accorded the safe guards that party A requires for this level of trust (as spelled out in the certificate's CPS). More comments below. Cheers, Chris John Ibbotson wrote: > > 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. A minor point of clarification here. ebMS uses an MSH-level Acknowledgment as the mechanism by which the receiving MSH node indicates to the sending node that the it has safely received the message. HTTPR, MQ and other approaches adopt different mechanisms to achieve the same objective. > 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. Agreed, although from a security aspect, authentication may need to be applied which may involve signature validation. > 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 > > <snip/>