>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.
Good point.
I think the SOAP model has not given much thoughts to
intermediaries that are mere "routers", and therefore we should not be too eager
to make the ebms multi-hop use case "fit in" this
model.
Clearly the concept of processing SOAP headers has been
defined assuming that whoever is targeted to do this processing, is the final
consumer of this header, and "re-insertion" appears to be mostly a kludge, a way
out some annoying corner case.
If we
have a rationale for NOT adding @role - and it looks like we might, given that
the notion of "header processing" falls short of supporting our case - I
am all for it.
By not
having this addition we also ensure that any message good for a
point-to-point exchange, can also be sent to the I-Cloud, given the right
routing function.
(we
should make this one of our basic principles)
If not
that introduces some embarrassing dependency to the
topology.
Jacques
From: Moberg Dale
[mailto:]
Sent: Friday, June 12, 2009 8:42
AM
To:
Subject: [ebxml-msg]
Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and
reservations
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.
