a bi-partisan proposal

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