a bi-partisan proposal

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

Here is a bi-partisan proposal for a change ;-)

 

1. The core of an "Intermediary role" specification should primarily focus on such functions as store-and-forward, bridging MPCs, rules for bridging MEPs e.g. allowing a received pushed message to be pulled, etc.

- The routing function has to be assumed, but can remain unspecified, as it may depend on various header data anyway.

- the RM function can be largely ignored when specifying the above.

 

2. Reliability function: a couple of options should be specified.

 

(a) Because there will be multi-hop configurations where the Sender knows enough about the ultimate receiver endpoint so that routing is not an issue even for RM signals,  the end-to-end RM sequence should be an option. Note that this option is straightforward for conformance profiles that make use of WS-Reliability (no RM signals besides Acks). When using WS-ReliableMessaging, it will require routing support for RM signals (e.g. use of WSA, or other means TBD).

This option is the only "fully transparent" end-to-end RM (e.g. for security) and this alone justifies to support it although not possible in all multi-hop configurations dues to routing constraints. It is also very straightforward in terms of itnermediary conformance - once the routing is resolved.

 

(b) Because there will be multi-hop configurations where the routing of RM signals cannot be done e.g. to establish a stable RM sequence between two endpoint MSHs (e.g. because of too much dynamics on resolving MSHs even if partners are known, or because security issues require to "hide" a portion of the cloud) then end-to-end RM sequences cannot be established. In that case, an advanced intermediary profile will support RM sequences "bridging", so that end-to-end delivery assurance is still possible at least for "At-Least-Once", "At-Most-Once" and "Exactly-Once" delivery. This bridging can involve some Ack relaying techniques that need to be specified so as to depart as little as possible from standard RM module behavior.

 

Clearly, some multi-hop topologies might combine both (a) and (b). E.g. the I-cloud includes a "hidden" portion that has a well-known "gatekeeper" intermediary. Regardless of how many intermediaries are involved between a Sender endpoint MSH and a "hidden" ultimate Receiver MSH, it is possible to use a single RM sequence from Sender to Gatekeeper, and a single RM sequence from Gatekeeper to ultimate Receiver, while reducing the RM sequence bridging to the Gatekeeper only (all other intermediaries of the I-cloud being "transparent"). A non-transparent Gatekeeper would make sense anyway as  it is possible that the QoS on the hidden I-cloud is different (e.g. a VPN), so some Security processing may need to take place on the Gatekeeper, e.g. validating a sig on the RM headers that are removed, or removing encryption.

 

Hope that may relieve the deadlock... or provide enough wiggle room to move one step further.

 

Jacques