OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: scenario: RM-transparent Intermediaries

RM-transparent Intermediaries
- 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)
- 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.
- 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]