|In addition to my other comments I would propose to use a name like ebint:ebmsaddress to express this element defines the address of an endpoint and that this information is used to route the message.|
On 4 jun 2008, at 23:14, Sander Fieten wrote:
See my comments inline in red.
On 4 jun 2008, at 21:48, Durand, Jacques R. wrote:
Do you consider the optional child elements part of the address information? To allow maximum flexibility on routing we could allow the eb:MessageProperties element to be part of the address information. Allowing this kind of flexibility will require out of band, and therefor out of scope, agreements between I-Cloud and endpoints on the available address information. Without such an agreements there's no guarantee that the I-Cloud will be able to route the message.
Summary of some off-line discussion that seem to bring the following consensus about routing aspects:
1- An (eb) Intermediary must be able to route ebms User Messages based the header content eb:UserMessage, as agreed before. In addition, an Intermediary must also be able to understand wsa ref parameter named "ebmsrouting" (with namespace:ebint= http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/Intermediary). This element is just a container for an eb:UserMessage element.
Even without considering the eb:MessageProperties being part of the addres information there's a question on what is required and what's not. I could imagine that not all environments need all the information contained in eb:MessageInfo, eb:PartyInfo and eb:CollaborationInfo to address endpoints. Making all information required in such situation is a bit unneccessary but doesn't do harm either.
My proposal is to define address information as the set of information consisting of the mpc attribute of eb:UserMessage and all information contained in the elements eb:MessageInfo, eb:PartyInfo and eb:CollaborationInfo.
Agree, but what if the address information contained in the WS-A address (the reference parameter ebint:ebmsrouting element) is not equivalent with the address information contained in the eb:UserMessage element and its child elements? I think such a message is invalid and should be rejected.
2- Whenever the "ebint:ebmsrouting" ref parameter is present, an Intermediary must use it for routing (even if an eb:Messaging/eb:UserMessage is there). If not present, the Intermediary will use eb:Messaging/eb:UserMessage if present. If none of these are present, the Intermediary expects to see a wsa:To that will be used for routing (which assumes the destination URL is known in that case).
Should these EPRs be included in PMode's? I would think that all information part of the EPR is already available in other properties of the PMode.
3- The Intermediary does not make an check on which messages such headers are piggybacked on: ebint:ebmsrouting could be on an RM signal message as well as on an ebms User message or on an ebms Signal message. Similarly, if a "dummy" eb:Messaging/eb:UserMessage is piggybacked on an RM signal (instead of ebint:ebmsrouting) the Intermediary should still route.
- wsa EPRs may be defined in the PMode associated with an MEP, both for forward routing and backward routing. The ref parameters will look like:
.... (with only the header elements values that are "invariant" for this PMode, i.e. common to all messages for the PMode)
That will translate in such SOAP header as:
Agree. I think we should require an endpoint to use the supplied address information in the wsa:ReplyTo element even if it has address information availble in one of it PMode's.
4- The EPR intended for the routing of response messages for this PMode, will be known from the initial Sender. It will also include a ref parameter as before that allows for routing these responses back. If appropriate, the response EPR may also mention directly the response address (or an Intermediary address) in the <wsa:Address> field of the EPR.
The response EPR should be indicated on the wire, in the wsa:ReplyTo (even if the destination has a copy of the PMode). This among other things enables an Intermediary to know where to send back eb:Errors related to routing failure.
I don't think it is a good idea to allow the use of dummy ebMS user messages without further specification. I think this will not help achieving interoperability. Even when out of band agreements are made the MSH's still have to understand and without further specification I don't know how this will be done.
5- The destination of all RM-related "response" signals (CSR, TSR, Acks...) is indicated in the wsrm:AcksTo element. This element used in the wsrm:CS must also be set to the response EPR specified in the PMode for all forward-going messages. In other words the destination of all response messages that result from the execution of forward-going messages: eb:Errors, eb:Receipts, various RM signals, is the same.
6- Note that if some endpoint MSH decides to just piggyback "dummy" eb:Messaging/eb:UserMessage header on their wsrm:CreateSequence, and not bother with wsa ref parameter <ebint:ebmsrouting> headers, they are still free to do so. This is not prohibited by V3 part 2. The routing must work. But they should have an out-of-band agreement with their endpoint partners that these dummy User messages are not to be delivered (or should be ignored if delivered), in case they need to set Service/Action to something else than the Core V3 "default" value (which in otherwise would guarantee non-delivery.)
7- An Intermediary is not supposed to have knowledge of PModes, except for the case where the Intermediary is connected to an endpoint that needs to do pulling, in which case at minimum the Intermediary needs to know (a) which MPCs are intended for pull, (b) what is the authorization data associated with these MPCs.
Still to be refined:
- Pulling cases (see Sander's) and also the pulling of eb:Receipts which may require at least the addition of @mpc to eb:SignalMessage (today only for eb:UserMessage).
- the special case of "sub-channels" allocated by an Intermediary (see use cases Pim & Jacques)