Hi, I'd like to try to summarize what we've talked at this thread. Fred - please feel free to challenge what I'm about to say :-)
Original problem : server-side outbound Policy interceptor assumes that no policy alternative has been asserted on the outbound path and reports a failure by (mistakenly) writing to the output stream. During the discussion (I think/hope :-)) we've mostly agreed that unless there's a really strong need for the application to depend upon the out verifier failing, this out verifier should do nothing, possibly just logging a message and perhaps do nothing at all in most cases. It's the role of the actual policy interceptors to take stronger action when necessary. The role of the verifier is to validate that those interceptors have actually done their work. Unless the (out) verifier is given some hints about the scope of a given policy expression, it can not reliably assert that just because this policy has not been asserted on the outbound path it means that the policy contract has not been fulfilled. Note that adding such hints only makes sense when it's of paramount importance that the out verifier validates that a given policy has been engaged on the out path. In other case they're not needed and thus the out verifier can keep quiet. Only when we do want the out verifier to fail (softly with WARNING or throw some exception) then it would make sense adding the hints to the policy expressions. One way to provide such hint is basically to do a custom implementation of PolicyAssertion and return the value based on the custom knowledge (similarly to the way interceptors tell about their phases). Another idea is to introduce new features to represent inbound or outbound only assertions. IMHO this is a bit too coarse-grained and introducing new features to represent some qualities of policies (in/out) may not be justified. That said this idea may be of help when dealing with tightly controlled 3rd party policy expressions (see next). Another idea is to introduce a custom attribute, to be added to individual policy expressions when needed. There's a concern that it may be too intrusive. IMHO the compactness and portability (can be applied to policies in the wsdl) of this solution outweighs these concerns. Futhermore, IMHO it's unlikely that adding such an attribute would cause any practical interop/policy validation issues - but if it will then we might be able to rely on previous proposal or come up with something else such that we can point to one or more of the assertions inside a given alternative (lists of qnames or xpaths at the existing policy feature, stripping out such attributes when publishing them, etc). I'd like to stress the fact that such hints may only needed when there's an explicit demand for the out verifier to validate if the policies have been used on the out path. Thanks, Sergey ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
