[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] NEW ISSUE: What is the effective policy when RM policy assertion is present at multiple places?
Anish, the text you quote as being in the spec is from the resolution to issue 21 [1, 2], it is not however in CD3 which is what most of us have to look at right now. Your proposed resolution says to make it clear how wsp:Optional is handled when the assertion is attached at more than one WSDL construct. We discussed this extensively in resolving issue 21 and I thought it was reflected in the resolution the TC accepted. I agree it is implied but not clarified by the text you quote, but isn't it clarified by the text describing the requirements when attaching the assertion to the input/output/fault? 1 Issue 21 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021 2 Issue 21 resolution (+ additional line notes in issue list) http://lists.oasis-open.org/archives/ws-rx/200603/msg00188.html Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/ -----Original Message----- From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] Sent: Wednesday, April 19, 2006 11:20 PM To: wsrx Subject: [ws-rx] NEW ISSUE: What is the effective policy when RM policy assertion is present at multiple places? Title: What is the effective policy when RM policy assertion is present at multiple places? Description: WSRMP spec currently contains the following text: "If the RM policy assertion appears in a policy expression attached to a wsdl:binding as well as to the individual wsdl:binding level message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:operation/wsdl:fault), the parameters in the former MUST be used and the latter ignored. If the RM policy assertion appears in a policy expression attached to a wsdl:port as well as to the other allowed WSDL/1.1 elements, the parameters in the former MUST be used and the latter ignored." Firstly, we do not define any RM policy assertion parameters, so I'm not sure what the above means. But it does give the impression that: RM-policy-assertion(port) trumps RM-policy-assertion(binding) which in turn trumps RM-policy-assertion(message). Given that we do not define any parameters the above statement doesn't mean anything expect in the context of wsp:Optional. Unless WS-Policy and friends define how wsp:Optional is dealt with in such cases, I believe we should define how things work in the realm of WSRM. Specifically: If wsdl:binding/wsdl:operation/wsdl:input (or wsdl:output or wsdl:fault) has <wsrmp:RMAssertion wsp:Optional='false'/> and wsdl:binding has <wsrmp:RMAssertion wsp:Optional='true'/> then the message-level assertion should trump the binding-level assertion (i.e. RM is mandatory for that message). The message-level assertion is more specific and that is the one that should be used (for that message) than the binding-level assertion. Similarly, If wsdl:binding has <wsrmp:RMAssertion wsp:Optional='false'/> and wsdl:service/wsdl:port has <wsrmp:RMAssertion wsp:Optional='true'/> then the binding-level assertion should trump the port-level assertion (i.e. RM is still mandatory for that binding). The binding-level assertion is a contract that must be adhered to by any port that uses it (one could argue that the assertion at the port is in violation of the binding contract). Justification: See above. Target: wsrm policy Proposal: Include language in the spec that makes it clear how wsp:Optional is handled when RM assertion is present at more than one WSDL constructs.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]