Re: [ebxml-msg] Comments on section 1.6 of Multi-hop Section Draft 0.11 (ebMS3-Multihop V11-SF.doc) uploaded

["Sander Fieten" <sander@fieten-it.com>]

Pim,

I agree with you that for forward routing the values to use for the WS-A EPR of the destination are already known and that there's no need for a separate PMode parameter. 

The intention of the current text however is to define the PMode feature, not how and where it is used. I'm also not sure if the PMode feature should be named RefParam, as it is more general about the use of WS-A. So WSA might be a better name.
As you indicated the EPR parameters are mostly needed for routing responses (reverse routing) and the RefParam feature will define the values to use for the EPR identifying the destination of responses which can be either WS-RM or ebMS signals. In the first case the PMode feature will define the values for the wsa:AcksTo and for the latter case the values for the wsa:ReplyTo.

Sander



----- original message --------

Subject: [ebxml-msg] Comments on section 1.6 of Multi-hop Section Draft 0.11 (ebMS3-Multihop V11-SF.doc) uploaded
Sent: Tue, 02 Sep 2008
From: Pim van der Eijk<pim.vandereijk@oasis-open.org>

>  
> 
> Lines 299 - 314, for forward routing, why do we need this new Refparam
> Pmode?  
> 
> When there is a need to create a WS-A reference parameter to route e.g. a
> wsrm:CreateSequence message, the content of the parameter could be a copy
> of
> the first eb3:UserMessage that wants to use the reliable sequence that is
> to
> be established.   This works both in situations where these sequences are
> created "just-in-time" and where they are created "ahead-of-time":  
> - In the "just-in-time" case, the MSH is creating this UserMessage anyway.
> If there is no(t yet or no longer any) sequence that the message can use, a
> wsrm:CreateSequence can be sent with the UserMessage stored in the
> reference
> parameters.
> - In the "ahead-of-time" case, the MSH could create sequences for all
> Pmodes
> that require reliability, using the regular Pmode parameter values.  
> 
> If the values for Party, Role, Service, Action etc. that would be used in
> the reference parameter are specified separately from the values for the
> UserMessage element,  we also suggest that (or have to explain the meaning
> of situations where) the values can be inconsistent, which I think is
> undesirable. 
> 
> For reverse routing, there is a valid question how the content of the
> reference parameter in the wsa:AcksTo element is set. In a Two-Way MEP, it
> could use the values for From, To, Service, Action etc. that would be used
> in a business response message. When using ebBP, such values can be taken
> from the RespondingBusinessActivity definition.  In many cases the values
> are predictable e.g. the From/PartyId becomes the To/PartyId (see section
> 1.5 of
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
> 
> _id=28337 for discussion), but the value of eb:Action depends on the
> business collaboration.  It also does not work for collaborations that are
> always One Way from one party to the other (i.e. where there never is a
> response business message that we could the header metadata values from).
> 
> Line 323-325
> 
> The text refers to the "RefToMessageId" attribute, for ebMS errors this
> should be "RefToMessageInError". For eb:Receipt, presumably the
> ebbp:OriginalMessageIdentifier if using ebBP receipts. 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 

--- original message end ----