Interesting analysis. There is a fundamental issue in combining
"ebMS-intelligent" routing, and the need to establish a fixed
reliability path (using RM seq lifecycle messages) prior to all reliable
exchanges to take place between two "multi-hop" parties.
WS-Reliability appears easier to deal with for 3 reasons: (a) no
separate lifecycle messages, (b) there is the option (like in ebMS2) to
*not* use sequence numbers, (c) the Ack semantics is on delivery, which
could mean "forward" for an intermediary. This makes it easier to chain
several reliable path segments.
This is something we will have to seriously consider. At this point it
looks like Part 2 - like Core part - cannot afford to ignore either
reliability spec.
Reliable (ordered) sequences are still something desirable, because they
allow for high performance and very robust duplicate detection, and loss
detection. But they assume the destination is resolved from the start.
WS-Reliability makes this a little more flexible (i.e. sender only has
to know what messages are for the same destination, vs. knowing the
destination).
With WS-ReliableMessaging, an approach could be: All routing is based on
wsa:To, which identifies the reliable destination (even if the routing
path may change). No ebMS-intelligent routing.
Chains of reliable segments appear unsafe, opening loopholes during
intermediary forward.
In all cases, it seems more important than ever to clarify the
requirements for multi-hop, and the use cases to be addressed.
Jacques
