cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 15:34:27 GMT

Hi Dan,

I'm a bit concerned here that we're proliferating different ways of
configuring things. 

Not that each individual mechanism isn't a good thing in itself, but
that the growing collection of different means to similar ends will
become difficult to test, document, demo, support tooling for etc.

Off the top of my head, we've about six different current or proposed
config-related mechanisms:

1. Spring beans
2. WS-Policy
3. WSDL extensions
4. Programmatic policy manipulation, e.g.
5. WSFeature
6. config embedded in URIs (as proposed by James Strachan)

Can't fault any individual one of these, but I'd worry that users would
find it all over-whelming and confusing. I'm not sure if combining some
of these (e.g. embedded policy assertions in WSFeature as you suggest)
would help or hinder here. Certainly its better than inventing a new
config syntax where there's already a preexisting policy. But it also
adds to the plethora of options as to where to hang the policy assertion
(i.e. a multitude of attachment points in WSDL, external attachments
applying policies to EPRs, and now WSFeatures also). So that choosing
the appropriate subject for the policy becomes non-trivial.

In the case of say the WS-RM policy assertion, what would be the
advantage of embedding this in the <jaxws:client><features> Spring
config, as opposed to having an external policy attachment applying the
same assertion to an EPR corresponding to the target port of the
<jaxws:client> bean?

Things are already getting confusing in terms of there some things can
only be configured via Spring, others via either Spring beans or policy
attachments, still others via WSFeature within Spring beans, etc. So it
mightn't be straight-forward for an individual user to just pick one
mechanism (say WS-Policy) and standardize all their config activity on

Note I'm not necessarily knocking WSFeature here, but I think we'd have
to be very clear about the delineation between all the above, and the
motivation for supporting them all (i.e. ask what extra expressive power
does WSFeature would give us).


> -----Original Message-----
> From: Dan Diephouse [] 
> Sent: 20 April 2007 08:23
> To:
> Subject: Some quick thoughts on WSFeature and Policies
> Hiya,
> I know we're very close to our 2.0-RC release, but I wanted 
> to see if I could quick finish off the wsfeature stuff. Its 
> not necessarily that much code. And I think there was some 
> consensus that this is generally a good thing, but I'd like 
> to garner some more feedback if possible.
> Quickly the idea is that we can configure WS-* features via a 
> bean like or xml interface:
> ServerFactoryBean sf = new ServerFactoryBean();
> feature = new WSSecurityFeature();
> feature.setTrustKeyStore(...);
> ...
> sf.addWSFeature(feature);
> Or in XML:
> <jaxws:endpoint ...>
>   <features>
>      <wssec:security>
>          ....
>      </wssec:security>
>   </features>
> </jaxws:endpoint>
> As stated previously, my thinking is that a WSFeature 
> construct is needed in CXF because:
> a) Not everything is configurable via policy. WS-Security is 
> a prime example
> - the ws-security policy doesn't encapsulate everything we 
> need it to for configuration, like information about 
> keystores. I noticed WS-Addressing has a feature as well 
> which isn't encapsulated in policy - the allow duplicates 
> flag on the MAPAggregator could be configured via this as well.
> b) Policy requires some extra configuration to set up (i.e. 
> policy engine
> enablement)
> c) A feature may want to customize a bus/server/client.
> d) policy may introduce unnecessary overhead? (I haven't 
> benchmarked this, so its hard for me to say at this point)
> (a) could possibly be addressed by writing new policies, but 
> I'm not sure that is the answer. I don't know that Policy 
> makes a stellar configuration language for everything. Going 
> back to my ws-security example, lets say I need to load a 
> KeyStore. This KeyStore could be from a file or even possibly 
> a database. If it was a database I would have to configure it 
> with lots of jdbc info. If we go 100% ws-policy, I would have 
> to write a policy to configure it. Whereas if I'm using a 
> bean based/spring approach I can just write <bean...> inside 
> my <trustKeyStore> element.
> Now the question in my mind is: how do we merge this 
> seamlessly with policy?
> I agree that there is some overlap. So I was thinking of 
> introducing a AbstractPolicyWSFeature class which would be 
> roughly like so:
> public class AbstractPolicyWSFeature {
>   public void setPolicies(Collection<Object> policies) {... }
>   public Collection<Object> getPolicies() { .. }
>   public void initialize(...) {
>    ... logic for ensuring the policy engine is enabled and 
> applying the policies to the server/client/bus would go here
>   }
> }
> Or in xml form:
> <client>
>   <features>
>     <reliablemessaging>
>       <policies>
>          <RMAssertion>...</RMAssertion>
>       </policies>
>     </reliablemessaging>
>   </features>
> </client>
> Now that all seems a little verbose, but it probably wouldn't 
> be that verbose in reality for users as
> a) the features would have sensible defaults so you would 
> only need to specify a policy if you were overriding the defaults
> b) it would seem that chances are high that they might have 
> their policy externally attached if they're writing policy 
> (via ExternalAttachmentProvider or via the wsdl attachments)
> Another option would be to allow inline policies at the 
> endpoint config:
> <client>
>   <policies>
>      <RMAssertion> ... </RMAssertion>
>   </policies>
> </client>
> Finally, I'm contemplating the name "Plugins" instead. I 
> could see this also applying to things like JMX configuration.
> Thoughts? Better ideas?
> - Dan
> --
> Dan Diephouse
> Envoi Solutions
> |

View raw message