On 11 mrt 2008, at 07:30, Durand, Jacques R. wrote:
Inline: <JD>
Original Message-----
From: Sander Fieten [mailto:sander@fieten-it.com]
Sent: Monday, March 10, 2008 12:01 PM
To: Durand, Jacques R.
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups - Multi-hop Signal Routing
(ebMS-Signal-Routing.doc) uploaded
All,
is it really no option to extend signal message with extra header
information to give intermediaries the ability to route them? Jacques
mentions, what I think, two main reasons why these message don't contain
this kind of information. But I do have two remarks on them:
- I'm not so sure signal messages aren't intended for business delivery.
The receipt signal for example could have value at the business level
because it could confirm in a legally valid way that a message was
received.
<JD> the TC decided to NOT have business headers in Receipts for a
reason. As I remember it was that validating the digest (for
non-repudiation of Receipt) - if ever done - is typically an operation
that is done separately from any business process - does not need to
surface into the application run-time that issued the User message. It
is more of a security service. Like for any other security validation,
the application needs be notified only in case of problem.
Now, if one really wants to deliver this Receipt to the application,
that is an implementation option that is still available: Since the
original MSH is generally persisting the User message until it can
validate the Receipt, it is easy to use this User message header to bind
properly the Receipt to the application layer.</JD>
<SF>I agree with you that for security services like encryption and signing the application level generally only needs to be involved when something is wrong. I think it might be different for a receipt signal as it may have business value when used for non repudiation. Then for legal purposes it might be required for the application level to be involved.
</SF>
- I agree that extra headers would be unnecessary overhead when the
message exchange is done peer-to-peer, so there's no need for routing
information. In a multi-hop situation however messages must include
information which enables intermediaries to route them to their
destination.
<JD> So because an endpoint (Core V3-compliant) MSH is not supposed to
implement additional features, and is not even supposed to know if it is
talking to an intermediary or just another endpoint MSH, our proposal is
here that the first intermediary (the "Gateway") adds the necessary
routing info. That way, the endpoint MSH behaves exactly the same in
peer-to-peer vs. I-Cloud situations: it does not have to care.</JD>
<SF>True, but this might lead to a situation where each MSH has a Gateway Intermediary next to it to enable it to take part in a multi-hop exchange. In my opinion that is a situation that should be avoided when possible and it might be better to change the core spec to enable core spec compliant MSH's to take part in a multi-hop exchange. When the extra elements needed are optional, a conformance profile could be used for multi-hop enabled MSH.
</SF>
Both the Receipt and Error signal do already contain this information by
the RefToMessageId attribute. Routing on this field would however
require each intermediary to have an administration of received message
ids with their related sender, otherwise the reverse path can't be
determined. I think we can agree that this isn't a very realistic
solution.
<JD> And I certainly do agree because that is not at all what we
suggested. In Option 1, the same header data as in he User message would
be used for Signals. The only difference is, the first intermediary on
the Signal path is adding this header, not the endpoint MSH. The only
"administration" needed on the Gateway intermediary, is to remember
header data from a User message until a response is obtained. No
preliminary set-up is needed to do that.</JD>
<SF>
This was just a general remark, not directed at your proposals. They indeed solve this problem.
</SF>
Therefor it seems reasonable to me to extend signal messages with header
information to make it possible for intermediaries to route them to
their destination.
<JD> I think it is not hard to find use cases where relying on "header
data" to route a Signal back home, is not a realistic solution at all.
An alternative like using wsa inside the I-Cloud (our Option 2) is more
attractive, because it leverages an important fact about Signals that
are responses to User messages: their destination is known from the
start, unlike the destination of a User message. (and in case their
destination had to be other than the User message origin, wsa ReplyTo
header still handles this quite well) </JD>