Pim:
Sure, WS-Reliability can handle both (a) and (b) cases -
assuming that the Sender knows which messages must belong to the same sequence
(something most P-Modes should be able to tell).
In other words, there are two subcases for
(b):
(b1) The Sender always knows which messages belong to the
same RM group/sequence, even if it does not know in advance what the destination
(end of route) will be. The assumption is here that we know an RM group will
always end-up in teh same destination MSH.
(b2) The Sender does not even have the knowledge that 2
messages it sends will end up in the same destination (even if it does not know
this destination as in b1). It is then unable to assign an end-to-end RM
group/seq to its messages.
So for (b1), there is a choice:
- use WS-RM but with an RM sequence bridging technique (no
end-to-end RM sequence, due to routing issues for RM
signals)
- use WS-Reliability with simply end-to-end RM sequences
(no routing problem). Advantage: the intermediary has nothing to do except
routing!
For (b2), WS-Reliability wouldn't help. Some RM sequence
bridging technique would be needed regardless of which RM spec is
used.
Now, if WS-ReliableMessaging gets built-in support in
several WS stacks, it should be accommodated, especially for cases (a). For
cases (b) it is not clear that what's in the WS stack in terms of WS-RM
implementation, can easily be manipulated to do this RM seq bridging. Certainly
a stack with an open-source implementation of WS-RM would help implement
this kind of intermediary.
About security:
Wouldn't what you suggest (the outermost int-to-int
security layer) amount to using some transient security like SSL provides? Also
the ebMS header can't be encrypted all the way if you need it for
routing.
Besides this, it is clear that several additional security
schemes can be supported, as the ebMS core model is not exclusive of additional
security headers. If an intermediary knows it is the "last one" on the way, it
can manage to not ask more from the next MSH than what core V3 conformance
requires.
Jacques
From: Pim van der Eijk
[mailto:]
Sent: Wednesday, February 13, 2008 7:04
AM
To: Durand, Jacques R.;
Subject: RE: [ebxml-msg] a bi-partisan
proposal
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
