As you write, I think the point of having ebMS intermediaries is that
they support routing based on the ebMS user message elements and decoupling
routing logic.
But I think we could distinguish between:
- making a routing decision based on a feature that is common to
all messages in a logical sequence, e.g.
To/PartyId. This is a simple lookup table, very easy to
implement. If we have this restriction, a sender knows which
messages will be delivered to the same recipient MSH,
even if it does not know what that MSH is or where it is located. All ebMS
message having that feature will be delivered to the same MSH and can be sent on
the same RM sequence.
- making a decision based on some feature that may not be
available on all messages in the same sequence. Here we have a potential
issue that messages sent on the RM sequence should get to the same MSH.
In
that case, we could impose some restriction that the routing decision is made
based on the
first ebMS message that is bundled with the sequence creation
message, and having a way of linking subsequent messages to that
established routing.
Going back to ebMS2 MessageOrdering, one way of doing this is
to require that all messages sharing the same values for ebMS
From/To/CPAId/ConversationId are sent on the same WSRM message
sequence and routed in the same way. This will make sure they will end up
at the same recipient MSH (even if the sender doesn't know what/where/who that
MSH is). This does require the intermediary to maintain a potentially
large set of <ConversationId, NextMSH> mappings. But SSL/TLS
terminators, load balancers etc. do this for SSL/TLS session
affinity/resuming routinely, and they can store up to hundreds of thousands of
session ids, so this isn't that unrealistic.
Pim
From: Moberg Dale [mailto:]
Sent: 12 December 2007 22:51
To: Durand, Jacques R.;
Subject: RE: [ebxml-msg] end-to-end RM
option in case of WS-ReliableMessaging
Some quick
responses
From: Durand,
Jacques R. [mailto:]
Sent: Wednesday, December 12, 2007 1:59
PM
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)
<Dale> I thought
that Pim explicitly stated that knowing where messages go beyond the entry GW is
not something the sender should have to know. This would increase management
headaches. Why not use some standard metadata for the routing. The
protocol requires that the Service and Action and Role values be known. Why not
use what the protocol requires for every message?
- 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.
<Dale> MPC is not
required in the ebMS header. I want to use required features, either To and From
or Service and Action, not something that is not required for the 1-way PUSH
case.
I don’t think we want
to make the profile for routing through intermediary rely on an optional
information item.
Features:
Piggybacking of an ebMS
"dummy" message on all RM sequence management
messages.
<Dale> Why not
create a special ebMS signal message?
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
<Dale> What if
they want to use both Service and Action for routing? Or To and From? Not
certain that this meets enduser configuration use cases in
general.
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
