RE: [ebxml-msg] Some routing questions

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Inline <JD>. 

-----Original Message-----
From: Sander Fieten [mailto:sander@fieten-it.com] 
Sent: Wednesday, March 05, 2008 12:54 PM
To: Durand, Jacques R.
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Some routing questions

Jacques,

in the "requirements document" assumption A.2 says that routing must be
based on information available in the header of the message without
saying in which part of the message. This could be either the ebMS
header or any other SOAP header. However it seems logical to me that
ebMS messages are routed based on information in the ebMS header.

<JD> agree that any data that originates in ebMS header, is usable by
the routing function in an ebMS intermediary. </JD>

Anyway, information needed for routing messages may not be encrypted, so
when information from the ebMS header is used it means the ebMS header
can not be encrypted. Duplicating the information to a non ebMS header
will indeed allow for encryption of the ebMS header, but I wonder why
one would do that as the encyrpted is also available in clear text (in
the duplicated header) ?
So, I think we should require clear text headers if assumption A.2 is
correct. Maybe we have to make the assumption more explicit by saying
that all the routing information should be available in the SOAP header
(which includes the ebMS header).

<JD> Yes we can assume all routing info is in clear in the SOAP header.
Although this assumption is sufficient for User messages, we still have
an issue with Signal messages such as ebMS Errors, and Receipts. These
clearly do not have sufficient routing info in their ebMS header. In a
point-to-point communication, their destination is determined by
configuration (Pmode or CPA). No problem there. But for multihop, it
appears that the intermediaries must be a bit smarter for routing these.
E.g. these  messages are in general "response" messages that correlate
with a previous message causing this response to occur. The intermediary
(at least the first one on the path of the signal) might have to
remember routing info from the correlated message to route back the
response.</JD>



Regards
Sander


Durand, Jacques R. wrote:
> Some routing questions we should answer:
>  
> - We have assumed so far that ebms routing is based on header fields 
> in eb:Messaging.
> Do we assume eb:Messaging is never encrypted? Or else do we assume 
> that the fields
> used for routing must be "replicated" in a new header that will never 
> be encrypted (something acting as the "delivery" header
> in RNIF?)
>  
> - inside eb:Messaging header, the routing of user messages is likely 
> done based on subelements in eb:UserMessage: eb:PartyInfo, 
> eb:CollaborationInfo, eb:MessageProperties, eb:PayloadInfo.
> Probably not based on eb:MessageInfo that only holds ID data and 
> timestamps.
> In that case, how do we plan to route the ebMS Receipt signal? And 
> other ebMS Error signals?
> These signals have none of all the above eb:Usermessage elements, and 
> only share eb:MessageInfo in common with  user messages. On the other 
> hand, because they are "response" messages, we know their destination 
> (or what is the last intermediary on its way). It appears that a 
> different routing function is needed for such response messages. 
> SHouldn't it rely on wsa?
>  
> Jacques

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php