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