[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 policyassertion is present at multiple places?
Marc Goodner wrote: > 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. Yes, it is not in CD3, but is part of issue 21 resolution and editors' draft. > 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 didn't see anything in the resolution that talked about wsp:Optional. But yea we did discuss wsp:Optional in the context of issue 21, but IIRC it was in the context of what wsp:Optional means wrt to input v. output messages. We didn't really say anything about how this is factored into merging policies when they are attached at various wsdl artifacts. > 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? > This requirement (to attach RM assertion at the binding- or port-level with wsp:Optional='true' whenever there is a message-level RM assertion) is what got me thinking. If you assume that RM-policy-assertion(port) trumps RM-policy-assertion(binding) which in turn trumps RM-policy-assertion(message) AND having a message-level assertion requires that there must be a binding- or port-level assertion, then the message-level assertion is completely pointless (as it will always be overridden by binding- or port-level assertion which must be present). What I find message level assertion useful for is: saying that RM is *required* for a particular message while saying at the same time that the port/binding will *support* RM for all other messages in that binding/port. But if binding- or port-level assertion always wins then I can never say the above, defeating the whole idea behind the resolution of issue 21. {I hope the WSP experts will educate me if this is already resolved by WSP and friends} -Anish -- > 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]