On Oct 8, 2008, at 5:16 PM, Sergey Beryozkin wrote:
Hi
I agree with what Dan suggested - logging a message in a
PolicyVerificationOutInterceptor should suffice in most cases. Few
more
comments.
I think that asserting a policy on the outbound path makes sense
only if
a specification for a given policy expression explicitly states that
it
applies to both inbound and outbound paths or to outbound path only.
Suppose you have this config:
<jaxws:endpoint ...>
<jaxws:features>
<cxf:PolicyFeature>
<wsp:Policy><foo:Bar/></wsp:Policy>
</cxf:PolicyFeature>
</jaxws:features>
</jaxws:endpoint>
Does <foo:Bar> apply to the inbound our outbound path? Or both? What
are the semantics here?
on the
server inbound path, a union of all policy expressions is selected
as at any
moment of time we may need to satisfy requests from clients meeting
either
all or one of the available alternatives.
All required interceptors are
installed - but the api allows for on-demand interceptors
installation (for
ex, based in the in message's content & headers).
Correct. Or more appropriately, based on the actual content of the
policy.
AFAIK,
PolicyVerificationInInterceptor would say OK as long as at least one
of the
alternatives is fully satisfied. In your example we have a compact
policy
expression, so there'no problems if either <foo:Bar/> or <gnu:Gnat/>
has
been asserted.
On the outbound path only the alternative which has been selected
during the
inbound path should be optionally verified. I don't think any
alternative
selection algorithm should apply on the outbound path as we already
have an
alternative active in the scope of a given operation.
That assumes the effective policy is the same on the inbound and
outbound sides. I think that's an invalid assumption (as I think you
are saying, as well). Or at least I think we should be able to
discriminate between inbound and outbound policies. I stand corrected
in the case of WSDL, but I think we need a way to make the same
distinction in spring (and however else we retrieve policy).
How about this, for a proposal:
<jaxws:endpoint ...>
<jaxws:features>
<cxf:PolicyFeature>
<wsp:Policy><foo:Bar/></wsp:Policy>
</cxf:PolicyFeature>
<cxf:InboundPolicyFeature> <!-- new type -->
<wsp:Policy><gnu:Gnat/></wsp:Policy>
</cxf:InboundPolicyFeature>
<cxf:OutboundPolicyFeature> <!-- new type -->
<wsp:Policy><bling:Blang/></wsp:Policy>
</cxf:OutboundPolicyFeature>
</jaxws:features>
</jaxws:endpoint>
So on the inbound side you'd get [{foo}Bar, {gnu:Gnat}]
And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]
If we have the Ex2
(above) then this alternative will simply have no any inbound
behaviors to
engage (see more below). In Ex1 - it's up to that specific policy's
out
interceptors to do any additional outbound work.
Thus, in many cases, like in Ex1, if no explicit out policy
interceptors
have been provided then PolicyVerificationOutInterceptor should
simply log a
(FINE?) level message as suggested. In fact it's not clear what else
it can
do other than do this logging on the server side.
I think this gets us over a hump, but I also think it's kind of a cop-
out. Why log anything? Why even do the check? What's the purpose,
if there's no tangible side-effect? Choke up a log with more garbage?
While (on the server side) PolicyVerificationInInterceptor is useful
in that
it ensures that at least one alternative has been met, its out
counterpart
is of little use. Unless we provide some hints.
Yup. If it's of no use, remove it.
We can introduce additional optional hints (in the form of policy
attributes) to both in/out verifiers that this policy only applies
to the in
or out path or to both paths. Thus, in case of Ex2, In verifier
won't fail
but Out verifier can log a WARNING (or throw a fault if its phase
can be
changed). Likewise, in Ex3, In verifier may throw exception while OUT
verifier will keep quiet. In case of Ex1, both in/out verifiers may
report
failures (through exceptions or logging).
Not sure what you mean here. Attributes on the wsp:Policy elements,
themselves? I'd think there'd be a better way to do that, than to add
proprietary stuff to standard policy expressions. At any rate, if
that's what you mean, then I think we should try to avoid it, since it
won't be in any way interoperable.
Without such helper attributes the default (server) behavior should
likely
be :
- PolicyVerificationInInterceptor throws fault if none of the
alternatives
has been met (as it is now)
- PolicyVerificationOutInterceptor logs a FINE message if not all of
the
expressions in the alternative selected during the inbound
invocation has
been met.
Why? What possible use is this to the user? The more I think of it,
the more I realize the PolicyVerificationOutInterceptor on the
outbound server side is kind of pointless, especially in light of the
current bug in its behavior.
I'll reiterate that the API on setting a PolicyAlternativeSelector is
too coarse -- it's on the PolicyEngine, which is basically in 1-1
correspondence with the Bus. I can think of 4 different ways you'd
want to configure one of these guys (client/server in/out), and you'd
want to be able to configure that on a per-endpoint basis (at least).
-Fred
