[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]