3 end-to-end RM scenarios

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