scenario: RM-transparent Intermediaries

Scenario: 

-------------

RM-transparent 
Intermediaries

 

 

Assumptions: 

-------------------

 

- the 
sender does not have to know the ultimate 
destination (MSH URL) of its messages, but it has to know whether two messages 
are intended for the same destination or not, because it has to assign every 
message sent reliably to an active RM sequence (and an RM sequence must go to a 
single RM destination).

 

- An ultimate MSH 
is also supposed to represent 
a single RM destination. But the same 
ultimate MSH could deliver to different parties (message consumers), i.e. 
different PartyID, different Service/Action, 
etc.

 

- the sender knows 
what fileds in a message are used to determine the ultimate destination (these fields are 
used for the routing function)

 

 

Features:

-------------

 

- Only the two 
ultimate endpoints are RM enabled. The Intermediaries are fully transparent: 
they do not touch the RM headers, nor related signatures etc. 

 

- The difficulty of this 
scenario is in the establishment of the RM sequence that will be used by user 
messages intended for the same destination. RM "sequence lifecycle messages" 
such as CreateSequence, TerminateSequence, and their responses, must be routed 
in the same way as ebMS messages. A way to achieve this is to piggyback RM signals on ebMS messages (either dummy user-messages, 
or signal-messages). This ebMS header would have same "determining header 
fields" as the future user messages intended for this 
RM sequence. 

 

- A piggybacking option is to use a "dummy" ebMS user message on all RM sequence management 
messages.

Advantage: no new ebMS signal needs be designed 
for this piggybacking : a "dummy"  user message has the service field set 
to: http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service

which is 
enough to process it correctly in core V3, i.e. to NOT deliver it to the MSH 
consumer layer. (that way, no additional feature is required from the 
destination MSH, other than core V3 compliance). We might want to specify a new 
Action field value, but no need to interpret it on receiver side. The drawback is that the Service field should not be 
one of the determining fields for routing...

 

- Another piggybacking option is to define a new ebMS 
signal, that would still have all the potential business headers used for 
routing.

 

- the response RM management messages need be 
routed back. Suggest to put the burden of the piggybacking for these responses 
on the last MSH intermediary, not on the ultimate MSH who should not be aware of 
the RM-thru-intermediaries aspects. So the 
communication between last intermediary and ultimate Receiver is unconstrained 
(e.g. get Acks on HTTP responses, etc), exactly as if the last Intermediary was 
the original sender in a one-hop.

 

 

Evaluation:

---------------

 

- Advantages: Very clear RM QoS: end-to-end RM is getting same 
level of reliability QoS than any one-hop RM exchange, and using the same RM infrastructure. 
Conventional RM modules are used (except 
for the fact the piggybacking of RM seq lifecycle messages must be controllable), and if 
the module supports duplicate detection for on-hop, will also work for multi-hop. But most of all, the intermediaries are really 
fully transparent: no overhead with RM headers substitution, no restriction on use of security (remember that RM headers are usually candidates for 
signing and other integrity protection). End-to-end security covers RM 
headers. 

 

- drawbacks: Need to design a piggybacking system 
introducing special ebMS messages, for routing the RM sequence management 
messages. The reliable "message 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 (might be indicated by P-Mode anyway). 

 

- do the initial 
sender / ultimate receiver need to support more than Core V3? Not receiver. But Sender implementation need be able to 
control piggybacking of RM signals. Although not really additional feature beyond Core V3 (unless a new signal introduced), it is a constraint on implementations.