OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: REFURBISHED ISSUE: i021


i021 freshened a bit:

 

Description:

Last sentence of Section 2 in RM-Policy spec says 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. However, clearly the DA requirements are different for each endpoint (Client and WS), and so are the performance requirements and capabilities regarding the protocol. For example, a WS may need ExactlyOnce for incoming messages, and consequently implement the protocol along with its receiving functions (sending Acks), but not willing to implement the RM sending functions (resending mechanism...) - or at least not with the same parameter values - if the responses need not be reliable. 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.)

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]