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: RE: [ebxml-msg] end-to-end RM option in case of WS-ReliableMessaging

some quick responses back...<JD>

From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Wednesday, December 12, 2007 1:51 PM
To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
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]
Sent: Wednesday, December 12, 2007 1:59 PM
To: ebxml-msg@lists.oasis-open.org
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? 


<JD> you misunderstood:  I meant: "which set of messages are intended for a same destination" - never assumed that this destination had to be known by the Sender. But when Sender has to make the decision to send messages over the same RM sequence, that means it knows they are all for the same [RM] 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.


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


<JD> Fair enough - I meant this recommendation for the user, not for the specification to restrict the routing options. I assume the routing criteria will be configurable and probably mentioned in P-Mode.




Piggybacking of an ebMS "dummy"  message on all RM sequence management messages.


<Dale> Why not create a special ebMS signal message? 


<JD> There may be two reasons to prefer a [dummy] user message:  (a) unlike signal messages so far, only user messages contain business header data, (b) Core V3 implementations are already capable of sending and processing such messages. On the down side, the current way to indicate a "dummy"  is to use a specific value in the Service field, and as you pointed out this rules out using Service in the routing function.  


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



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