Hi
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?
This coarse-graned policy applies to an endpoint so as I said it's up to the <foo:Bar/> implementation as to whether it will affect
in/out/both pathes. As far as the policy verification is concerned, the default behaviour is to fail on the inbound path if a single
alternative includinfg a single <foo:Bar/> policy expression has not been asserted and (to be fixed) log a message on the outbound
path.
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.
Not necessarily. Consider an optional MTOM policy assertion. There's no strict
need to install an MTOM interceptor
in advance, untill a given message arrives. You can 2 messages coming in, one
is non-MTOM, another one is.
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).
I actually think that the single effective policy should apply to the given operation, in/out. But this policy can contain
expressions which are valid for the outbound only or inbound only or both. I don't think WS-Policy provides for effective polices
for in or out only, It's a single effective policy instance for the scope of a given operation. Though the AssertionInfoMap should
be in/out-specific.
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>
I'd just prefer
<wsp:Policy><bling:Blang cxf:scope="default/in/out"/></wsp:Policy>
IMHO this is more compact and easier on the eye. Furthermore, when such policies will be dynamicallyt attached to WSDL instance, it
would provide more hints to client runtimes/tools. Such attribute can also be applied when polices are explicitly attached to WSDL.
For ex, as I said earlier, there's no explicit indication to verifiers on the scope of this policy when it's attached to some
container element like wsdl:port
<wsdl:service>
<wsdl:port>
<wsp:Policy><bling:Blang/></wsp:Policy>
</wsdl:port>
</wsdl:service>
we have a PolicyAssertion abstraction and we can add a helper method like getScope(), by default it applies to say 'in' only or
in/out with possisble overrides.
To be honest though, I wouldn't be too concerned now about ensuring that outbond policy verifier fails (or reports a warning). I
reckon the default behaviour (of just logging some FINE message) would do in case say <bling:Blang/> ends up in the list of
policies. Only when it's absolutely critical that an outbound message does not leave the server runtime if some policies have not
been applied to the outbound message (SLA agreement with non policy aware client runtimes for ex) then I'd consider adding such
hints.
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?
So we can have a default scope be "in-only", but when we want to block the
response we can override it.
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.
Mostly agreed but see above - we might need it at some time. And it's probably
can behave differently on the client side.
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.
any client runtime should be able to ignore unrecognized attributes. Any policy
expression
should have an extension point for any additional attributes. I honestly think
it's an issue at all.
If we ever have to deal with 3rd party policies with closed schemas then we can
also use your proposed
extension.
We can also suggest to the ws-policy group to consider standardizing on such attribute (as it can be of real help to client
runtimes) in the next maintenance release of the spec, whenever it happens.
Cheers, Sergey
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?
See above please.
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).
And I'd like to stress again that PolicyAlternativeSelector is really not
needed at all and it needs to be deprecated.
On the server side any of the many available alternatives can be valid at any moment of time for a given message and once the
effective policy is calculated it should stay fixed for the outbound path. Thus no need for any special alternative algorithms on
the server.
On the client it's none needed either - the client needs to iterate through all
the available alternatives and find the best one.
Cheers, Sergey
-Fred
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
