cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject RE: More on server response policies
Date Thu, 09 Oct 2008 21:10:40 GMT
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

Mime
View raw message