Hello Jacques,
If WS-Reliability is considered as an option, could it provide
end-to-end reliable messaging in situation 2 (b) too? Assuming a constraint that
the reliable messaging headers must be piggy-backed with ebMS headers (assuming
routing is based on these ebMS headers). When the sender
knows which messages will end up at the same MSH (even if it does not
know which particular MSH), it could send these messages as a group.
If
it does not even know this, it could use groups of cardinality one,
functionality that ebMS 2.0 reliable messaging provides today. Security would be
preserved too.
When end-to-end reliable messaging is not used,
perhaps we
need to consider two separate wsse:Security blocks to secure the
exchange:
1: One that signs the complete SOAP with attachments
message, including any WS-A and WS-RM headers, targeted at the next
MSH.
2: A second header that signs (and encrypts) only the
ebMS 3.0 header and all payloads, targeted at the ultimate receiver
MSH.
An intermediary would remove the first wsse:Security header
block and re-sign the message. The second wsse header, the
ebMS 3.0 header and all payloads would be copied. In this scenario,
the intermediary can forward messages in different sequences, not
necessarily to the same ultimate receiving MSH, and it can even deliver some
messages locally. An intermediary needs sequences to deliver to its
associated endpoints and for any other intermediaries. Each intermediary is an
end-point for WS-A and WS-RM processing, except for the special ACK
"relaying" functionality.
I know proposing a second
header violates the requirement that endpoints should not have to behave
differently to support intermediaries, but we need to balance that against the
requirement of end-to-end
security.
Pim
From: Durand, Jacques R.
[mailto:]
Sent: 13 February 2008
05:07
To:
Subject:
[ebxml-msg] a bi-partisan proposal
Here is a
bi-partisan proposal for a change ;-)
1. The core of an
"Intermediary role" specification should primarily focus on such functions as
store-and-forward, bridging MPCs, rules for bridging MEPs e.g. allowing a
received pushed message to be pulled, etc.
- The routing
function has to be assumed, but can remain unspecified, as it may depend on
various header data anyway.
- the RM function
can be largely ignored when specifying the above.
2. Reliability
function: a couple of options should be specified.
(a) Because there
will be multi-hop configurations where the Sender knows enough about the
ultimate receiver endpoint so that routing is not an issue even for RM
signals, the end-to-end RM sequence should be an option. Note that
this option is straightforward for conformance profiles that make use of
WS-Reliability (no RM signals besides Acks). When using WS-ReliableMessaging, it
will require routing support for RM signals (e.g. use of WSA, or other means
TBD).
This option is the
only "fully transparent" end-to-end RM (e.g. for security) and this alone
justifies to support it although not possible in all multi-hop configurations
dues to routing constraints. It is also very straightforward in terms of
itnermediary conformance - once the routing is
resolved.
(b) Because there
will be multi-hop configurations where the routing of RM signals cannot be done
e.g. to establish a stable RM sequence between two endpoint MSHs (e.g. because
of too much dynamics on resolving MSHs even if partners are known, or because
security issues require to "hide" a portion of the cloud) then
end-to-end
RM sequences cannot be established. In that case, an advanced intermediary
profile will support RM sequences "bridging", so that end-to-end delivery
assurance is still possible at least for "At-Least-Once", "At-Most-Once" and
"Exactly-Once" delivery. This bridging can involve some Ack relaying techniques
that need to be specified so as to depart as little as possible from standard RM
module behavior.
Clearly, some
multi-hop topologies might combine both (a) and (b). E.g. the I-cloud includes a
"hidden" portion that has a well-known "gatekeeper" intermediary. Regardless of
how many intermediaries are involved between a Sender endpoint MSH and a
"hidden" ultimate Receiver MSH, it is possible to use a single RM sequence
from Sender to Gatekeeper, and a single RM sequence from Gatekeeper to ultimate
Receiver, while reducing the RM sequence bridging to the Gatekeeper only (all
other intermediaries of the I-cloud being "transparent"). A non-transparent
Gatekeeper would make sense anyway as it is possible that the QoS on the
hidden I-cloud is different (e.g. a VPN), so some Security processing may need
to take place on the Gatekeeper, e.g. validating a sig on the RM headers that
are removed, or removing encryption.
Hope that may
relieve the deadlock... or provide enough wiggle room to move one step
further.
Jacques
