Scott Hinkelman wrote: > > Question: > >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. > > What does this mean exactly? Does this mean that the A-B CPA contains > information, > say a URL, about B1? Nope, only about B. B1 is invisible from A's perspective. A and B1 can still share a CPA as can A and B. Between B and B1 there may be something else about which we say nothing. No Via is necessary IMO in the scenario I outlined because the routing application software at the B MSH node is free IMO to effect the routing any way that it chooses. Cheers, Chris > > Scott Hinkelman, Senior Software Engineer > XML Industry Enablement > IBM e-business Standards Strategy > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) >
srh@us.ibm.com, Fax: 512-838-1074 > > christopher ferris <
chris.ferris@east.sun.com>@Sun.COM on 08/31/2001 > 07:08:28 AM > > Sent by:
Chris.Ferris@Sun.COM > > To:
ebxml-msg@lists.oasis-open.org > cc: > Subject: Re: reliable messaging - hop by hop > > 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/> > > ---------------------------------------------------------------- > 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 >