[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] end-to-end RM option in case of WS-ReliableMessaging
|
Some quick responses From: Durand, Jacques
R. [mailto:JDurand@us.fujitsu.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]