In order of priority, I think that the main elements
that routing applications would want to use for routing decisions are:
- To/PartyId (for
- To/PartyId/@type
- Service (for SOA-style
messaging)
- Action
- ConversationId (for ebMS business session
affinity)
- MessageProperties (e.g.
"indicatorMessageIsATestMessage")
I.e. routing based on user message elements rather than
signal message "mpc" elements, as implemented by multiple ebMS2 products
and used in some ebMS2 deployments
today.
I assume you are suggesting bundling with an ebMS
signal to avoid having to send a User Message bundled with an
(unreliable) sequence creation message. But perhaps we
can require some special ebMS processing support for this particular User
Message, e.g. some way of requiring an eb:Receipt at the ebMS level
binding?
(This might also require an ebMS-level retry,
if just for this sequence creation piggy back message case; and this might
also require a different eb:MessageId, in order to avoid duplicate elimination
at the WS-R/WS-RM level). Or perhaps we
should extend the Signal Message with elements from the User Message (optional
to remain compatible with Part 1).
If the only parameter
available for routing is an mpc name string, the first thing I
would put in those mpc names would be concatenations of PartyId, Service
etc. which to me shows we are missing some generalization here
...
From: Durand, Jacques R.
[mailto:]
Sent: 12 December 2007
21:59
To:
Subject:
[ebxml-msg] end-to-end RM option in case of
WS-ReliableMessaging
Following the
end-to-end RM option for a Push mep in case of
WS-ReliableMessaging:
Assumptions:
(actually needed whenever RM sequences are used, regardless of which reliability
specification)
- the sender always
knows which messages are for the same destination, even if the decision about
what this destination is (URL) is left to the routing function. A destination is
also supposed to map to a single RM destination (i.e. there are not two RM
Destination modules serving the same business destination)
- the sender knows
what fileds in a message are used to resolve the routing path, so that a dummy
ebMS [user] message can be crafted to establish the RM sequence prior to sending
actual user messages. Recommendation is: to simply use MPCs as routing
means.
Features:
Piggybacking of an
ebMS "dummy" message on all RM sequence management
messages.
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.
- teh 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.
Comments: all this
is about using ebMS intermediaries. Clearly, alternative forms of multi-hop
routing can apply to achieve end-to-end reliable exchanges, such as SOAP
intermediaries (non-MSH) that use WS-addressing wsa:To, wsa;From or
wsa:Action headers. Both styles can co-exist: such SOAP nodes
could be intertwined with MSH intermediaries on a path. We do not specify that
one. In that case, different nodes on a path will use different routing info
(e.g. wsa header vs. ebMS header).
Jacques
