Yeah, I think this summarizes it well.
On Oct 9, 2008, at 5:10 PM, Sergey Beryozkin wrote:
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.
Correct -- and in general, this will only happen if there is an
alternative of cardinality > 1.
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.
Correct. Dan, you: +1 on logging (FINE or lower log level). Me: +1
on removing the validation out interceptor (outbound server side
only), since it's doing nothing put churning cycles and possibly
confusing the user.
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.
All three ideas amount to essentially the same idea: that the
effective policy (hence the policy vocabulary, hence the contents of
the AssertionInfoMap) is possibly different on the inbound and
outbound interceptor chains. /How/ that's done is probably less
important that /that/ it be done, because I don't think the current
way is really workable -- Right now I have to hack my way through the
outbound response AssertionInfoMap, checking off Assertions that have
already been checked off on the inbound channel, which is a hack
(requires that I artificially store data on the Exchange, etc), and
just adds extra overhead to the runtime.
-Fred
