← Prev in month ← Prev in thread

RE: NEW ISSUE: What is the effective policy when RM policyassertion is present at multiple places?

From
Ashok Malhotra <>
Date
2006-04-20T14:29:30+00:00
ID
20060420073256480.00000002264@amalhotr-pc
Thread
RE: NEW ISSUE: What is the effective policy when RM policyassertion is present at multiple places?
New issue raised by Anish re. RM Assertion.

All the best, Ashok
 

> -----Original Message-----
> From: Anish Karmarkar [mailto:] 
> Sent: Wednesday, April 19, 2006 11:20 PM
> To: wsrx
> Subject: 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.
> 
> 
>
← Prev in month ← Prev in thread