3 end-to-end RM scenarios

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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