RE: [ebxml-msg] end-to-end RM option in case of WS-ReliableMessaging

Dale:

 

some quick responses 
back...<JD>

From: Moberg Dale [mailto:] 

Sent: Wednesday, December 12, 2007 1:51 PM
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? 

 

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

 

 Features:

 

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

 

Jacques