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.
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.