Re: reliable messaging - hop by hop

[Scott Hinkelman <srh@us.ibm.com>]

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?

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>