OASIS ebXML Messaging Services TC

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

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?







- 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

 
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:dmoberg@axway.com]
Sent: 12 December 2007 22:51
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?


- 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

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

 
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:JDurand@us.fujitsu.com]
Sent: 12 December 2007 
21:59
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)
- 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