OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: reliable messaging - hop by hop

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.



> 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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC