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. ((HTTPCondiut)client.getConduit()).getClientPolicy().setAllowChunking(tr ue)). 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 this. 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). Cheers, Eoghan > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 20 April 2007 08:23 > To: [email protected] > 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 > http://envoisolutions.com | http://netzooid.com/blog >
