Hi
I'm about to submit the patch which attempts to change the way mutiple policy
alternatives
and nested policies are dealt with.There's a number of things which still would
need to be refactored and tuned, but some initial refactoring needs to be done
anyway.
Currently, policy alternatives are not selected correctly on the server side,
that is a single alternative is ever selected,
while in practice, a server should be able to satisfy mutiple alternatives as
different clients can choose diffent alternatives.
So the server will support all assertions in all the alternatives by providing
all the interceptors needed for a given endpoint.
This is an 'eager' approach, for the types of polices we support at the moment
it works just fine, but for more sophisticated
policies, such as those which will come from WS-SecurityPolicy it would not be
ideal.
Thus another thing which I've done is I've updated a PolicyInterceptorProvider
interface to provide interceptors given a current Message, for ex :
List<Interceptor> provideInInterceptors(Message m);
These methods are delegateing to default get{in/Out}Interceptors() methods for
now, but going forward, it would be better for policy interceptor providers to
provide interceptors lazily. For ex, AddressingPolicyProvider can check if the
message contains
a WSA header and if yes then add MAPAggregator into the chain, etc. Also, at
the moment PolicyInterceptorProviders are somehat detached from the actiual
Policy instances. I actually think Policy instances should themselevs be
Interceptor providers. But it's something we can discuss later.
Another fundmamental change I've done is that now Policy instances are asked
'personally' whether they've been asserted or not :
boolean is Asserted(AssertionInfoMap)
The reason for it is that in the presense of multiple alternatives and
especially in the presense of nested Policies, it's really a given Policy
instance which can reliably tell whether it has been asserted by checking its
nested policies if any, etc, or not.
Thus I had to introduce a PolicyAssertion interface which extends an Apache
Neethy Assertion interface.
For ex :
<wsp:Policy>
<!-- Alt 1 -->
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:TransportToken>
</sp:TransportToken>
</wsp:Policy>
</sp:TransportBinding>
</wsp:All>
<!-- Alt 2 -->
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDesRsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
</wsp:All>
</wsp:Policy>
What does it mean to have a TransportBinding be asserted ? Does it even has to
be asserted and may ve only its leaf assertions such as TripleDesRSA15 need to
be asserted ? Thus it's better for Assertions themselves to decide.
I've also found that the utility of JAXBAssertions is somewhat limited, they're
really suitable for primitive assertions only and one needs to write a utility
code on top of them anyway to deal with individual policy data.
There's a number of other refactorings which needs to be done but there're few
ones which would be on top of my list :
1. Policies attached through jaxws:endpoints should be published on demand
either in WSDL or in EPRs, this issue is blocking few other things.
2. Remove the AlternativeSelectors altogether or refactor them such that they
actually work. The problem with them is that they just don't work well. On the
server side the idea of selecting a given alternative only is not viable, while
on the client side it's not reliable. For ex, on the client side, the runtime
should select the alternative which suits the requirements, thus saying that
either the 1st one or last one or minimal alternative gets chosen is not a
reliable thing to do, a client can be presented with multiple alternatives,
with some of them containing assertions with nested Policies with even more
alternatives, and it's not feasible to reliably set in advance which
alternative should be selected.
3. Policy Intersection so that clients can choose between multiple services
dynamically or choose a given alternative based on its own requirements. For
ex, if we have a jaxws:client with a policy A and we have a service'WSDL with a
policy A and B then A will be selected through the intersection. Using
intersection or the current state of the message to choose a given alternative
is what clients would ideally do instead of using eager Alternative Selectors.
Cheers, Sergey
> All good points.
>
> I'd add that we need better config granularity of the PolicyEngine.
> Currently, as I understand it, a PolicyEngine is a Bus extension, so
> it's basically 1-1 on a bus. That's fine, as a Bus extension. But
> the PolicyEngine also is the place to configure AlternativeSelectors,
> which you might prefer to have configurable at endpoint granularity
> (or even policy subject granularity, though it's a bit harder to
> imagine how that might work).
>
> The same goes for the PolicyInterceptorProviders and the
> AssertionBuilders -- these are configured per-Bus, as I understand
> it. But we might want finer-grained config in some cases (E.g., use
> these policy interceptor providers for these endpoints, those for
> another, and yet another set by default).
>
> -Fred
>
> On Jan 29, 2008, at 8:23 AM, Sergey Beryozkin wrote:
>
>> Hi
>>
>> CXF WS-Policy framework needs a bit of refactoring. While it's
>> already quite sophisticated in what it can do, and some of its
>> features are really cool, like the ability to add JAXB derived
>> assertions, the ability to attach policy expressions externally and
>> inline from Spring using WSPolicyFeature, etc, etc, there're few
>> things which need to be fixed a bit :
>> * how various policy subjects contribute to corrresponding effective
>> policies
>> * how policy alternatives are selected on the server and on the
>> client (generally a server has to support all the alternatives while
>> the client can select only a single one)
>> * automatic policy publication on the server side
>> * policy engine needs to be enabled by default, etc...
>>
>> As such some breaking changes to interfaces like EndpointPolicy
>> (which itself may go in the end, with Policies just keyed by the
>> type of policy subject), PolicyEngine, may need to be applied. CXF
>> does not allow for alternative PolicyEngine or EndpointPolicy
>> implementations be injected anyway. This should not have any adverse
>> affect on any applications out there, if any, which do rely on
>> WSPolicy expressions, perhaps those dealing with WS-Addressing or WS-
>> RM or MTOM...
>>
>> Cheers, Sergey
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
