resending Reworded [i021] (a previous update was not reflected in today's issue ist):

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

Description:

 

Section 2 in RM-Policy suggests that an RM policy must apply to all messages in a binding (when associated to binding). That means applying equally (same timing parameters, etc.) to both in and out messages of an operation of type request-response. Do we assume that the reliability requirements are same for each endpoint (Client and WS)? (meaning the protocol requirements and capabilities). Seems too constraining: for example, a WS may need ExactlyOnce for incoming messages but not for its responses, and consequently not willing / needing to use the RM protocol for responses (resending mechanism...) - or at least not with the same parameter values.

In addition, when deployed in a WS-I-compliant (Basic Profile) environment, a reliable Response has to be sent over an HTTP response. The RMS behavior (which is now the sender of the Response) would need to implement a much more constrained and context-dependent resending mechanism, as response messages can only be resent as responses to request resendings.

                                      

 

Justification:

 

Enforcing same protocol policies for inbound and outbound messages may create unnecessary burden to a WS endpoint for which RMD-only functions are sufficient. In addition, the resending behavior for synchronous responses being more constrained, cannot obey the same parameters.

 

 

Proposal:

 

A couple of proposal directions (either / or):

 

1. Assert somehow that RM policy assertions are "oriented" by default, i.e. only apply to all "in" messages from a Client to a WS endpoint unless specified otherwise.

 

2. Attach policy assertions at message level if needed (or provide means to override at message level, e.g. attach a "void" policy to an out message, if no reliability needed here.)

 

 

Thanks,

Jacques