1. Versions: Is this
section intended to apply to SOAP 1.2 only?
If so, is the first or
second edition of 1.2 relevant?
2.There is a SOAP
processing model mentioned in http://www.w3.org/TR/soap12-part1/
but nothing explicitly referred to by “SOAP intermediary model”
But consider Section 2.7 in
the second edition, entitled, “Relaying SOAP Messages”:
As mentioned earlier in this
section, it is assumed that a SOAP message originates at an initial SOAP sender
and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries.
While SOAP does not itself define any routing or forwarding semantics, it is
anticipated that such functionality can be described as one or more SOAP
features (see 3. SOAP Extensibility Model). The
purpose of this section is to describe how message forwarding interacts with
the SOAP distributed processing model.
ebMS does not make use of
the SOAP Extensibility Model to define forwarding. Therefore, what we are doing
is not what “is anticipated” So, should we really be discussing
compliance? What exactly is it that we are complying with? WS-I has not
released any conformance Rxxxx requirements targeted at intermediaries that I
recall. We are not using the extensibility model. I think the title of our
section 2.4.5 is misleading.
3. “It is assumed
that ebMS Intermediaries are also SOAP intermediaries. By default all nodes
in the multi-hop path act in the “next” role (http://www.w3.org/2003/05/soap-envelope/role/next).
Replace “by default”
with “Therefore”
4. In the SOAP processing
model for intermediaries,
any header that is understood and processed must be removed from the SOAP
message.
Remove “for
intermediaries”
5. “If one wants
the headers to be available to further SOAP processors on the message path the
headers have to be “reinserted” in the SOAP message. When a SOAP
intermediary does not process a header it may relay this header to the next
SOAP node, i.e. not remove the header from the message.”
“As the routing
function of the ebMS Intermediary requires processing of SOAP headers these
headers are not subject to “relay” but to “reinsertion”
[SOAP12]. As relaying does not apply to the ebMS headers, the
@relay=”true” attribute should not be set. The ebMS routing
function is then a “header reinsertion” case.
”NOTE: When the
intermediary would reinsert header attributes by removing them first and then
add them again this might break signatures. It is therefore strongly
RECOMMENDED that intermediaries do not alter in any way the SOAP header of
routed messages, i.e. implementations must consider the “reinsert”
operation as a virtual extraction and reinsertion of header blocs. An
intermediary implementation SHOULD NOT rebuild the SOAP header of routed
messages by actually extracting then reinserting header blocks.”
Please reduce this to a
statement of the required functionality and do not describe how implementation
should occur (IMO!) Put something like “Header processing by an
intermediary MUST not break digital signatures.”
7. NOTE:
set the @role of all headers to “next”, as that does not seem to be
a default in SOAP1.2 ?
The “@role”
is a 1.2 attribute. What happens for SOAP 1.1? Why do we want all headers to
have that role? Why is the wss header set that way? We at most only want to set
the role value to “next” for the header containing metadata
consulted by the intermediary. What about mustUnderstand? For the ebMS header,
we do not want a mere SOAP intermediary to throw a SOAP fault because it does
not grok ebMS. And we should architecturally allow mere SOAP intermediaries.
But by targeting “next” and requiring ebMS header processing, we
block things. We really need to understand which header needs to be targeted
and what the target value should be? We might well be better off making up our
own role value here.