Overall summary of
actions items about the 3 end-to-end RM scenarios to
investigate:
Note: please reuse
the scenario name in the subject line of any email related to this scenario, for
convenience.
Assumptions:
- the use of RM
sequences is assumed (as opposed to ebMS ID-based RM like in
ebMS2).
- the routing
assumed here is based on info found in the ebMS header.
- the use of
WS-ReliableMessaging is assumed (knowing that solutions for WS-RM are also valid
for WS-Reliability)
Scenario editors should provide a more detailed
description of each scenario, and (along with anyone else) complete or provide
workarounds for the list advantages & drawbacks for each scenario.
Jacques
-------------------------------------------------------------------------------------------------------------------------------------------------------
1- the "Rekayed
Acks" scenario. Editor: Sander.
Every segment on the
path is RM-enabled. Acks are "chained" back to the initial sender (i.e. an Ack
is sent back by an intermediary only when it got the corresponding Ack from next
intermediary.)
- Advantages: the
reliable "equivalence sets" need not be known in advance by sender: the initial
sender does not have to know what are the messages intended for the same
destination (i.e. for same sequence).
- drawbacks: RM
modules need some adaptation work (do more than what RM spec requires), the
chaining of Acks macks the ack mechanism more complex and weakens its
robustness, some duplicate cases are not detected (e.g. during forward of
message) unless impleemnted at ebMS level, and intermediary manipulates RM
headers (end-to-end security is restricted).
- do the initial
sender / ultimate receiver need to support more than Core V3?
No.
-------------------------------------------------------------------------------------------------------------------------------------------------------
2- the "2-tier RM"
scenario. Editor: Jacques.
Every segment on the path is RM-enabled. In addition,
an ebMS "synchronization" signal allows for communicating ebMS message IDs
sent/received, so that each endpoint has awareness of
losses.
- Advantages: use
conventional RM modules, and segment-level RM is done in the most conventional
way. The ebMS sync signals used on top can be considered a useful feature in
itself, so not an overhead for implementing this.
- drawbacks: the
reliable "equivalence sets" need be known in advance by sender, at least until
the last intermediary: the initial sender has to know what are the messages
intended for the same destination. Some duplication cases cannot be detected
(unless ebMS-level implementation). Intermediary manipulates RM headers
(end-to-end security is
restricted).
- do the initial
sender / ultimate receiver need to support more than Core V3? Sender yes: need
be able to issue and interpret the sync signals (the last intermediary handles
these on behalf of ultimate receiver).
-------------------------------------------------------------------------------------------------------------------------------------------------------
3- the "RM-transparent
intermediary" scenario. Editor: Jacques.
Only the two ultimate endpoints are RM enabled. The
Intermediaries are fully transparent: they do not touch the RM headers, nor
related signatures etc. RM signal messages are piggybacked on ebMS messages
(either dummy user-messages, or signal-messages) to ensure consistent
routing.
- Advantages:
end-to-end RM is getting same level of reliability QoS than any one-hop RM
exchange. Conventional RM modules are used (except for the fact the piggybacking
of RM seq managememnt messages must be controllable), and if the module supports
duplicate detection for on-hop, will also for multi-hop. The intermediaries are
really fully transparent: no overhead with RM headers substitution, security is
not impacted.
- drawbacks: Need to design a
piggybacking system introducing special ebMS messages, for routing the RM
sequence management messages. The reliable "equivalence sets" need be known in
advance by sender, at least until the last intermediary: the initial sender has
to know what are the messages intended for the same destination.
- do the initial
sender / ultimate receiver need to support more than Core V3? Somehow Sender
implementation need be able to generate the "dummy" user message, and control
piggybacking of RM signals. Although not really new spec features, but
implementation capabilities.
-Jacques