> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 20 April 2007 16:59 > To: [email protected] > Subject: Re: Some quick thoughts on WSFeature and Policies > > Re: #4 - do we have a way to do programmatic policy > manipulation that isn't associated with transports?
I guess it would depend on how each configured object is (a) created and managed and (b) whether it exposes an accessor for its policies. > i.e. what > would be the recommended way to assert a RMAssertion on my > service via the API? I'm not sure. Maybe something like PolicyEngine.setEndpointPolicy() if the policy engine were available as a Bus extension of some-such. But I guess this is part of the point I'm making, that we've multiple config-related mechanisms that sometimes intersect and sometimes diverge. So suppose a user want to configure two aspects of the runtime, call them A and B. The choice of mechanisms available to configure A (e.g. Spring or WS-Policy) may well be different to the choice available for B (say Spring or programmatic). Note this is not an objection to WSFeature per se, just a warning light as to where we're headed in general with multiple config mechanisms. > Also, I would classify WSFeatures as a part of the Spring > bean configurations, since they're essentially part of the > *ServerFactory/*ClientFactory classes IMO. Are these proposed WSFeatures the same thing as the JAX-WS 2.1 javax.xml.ws.WebServiceFeature idea (that can be passed programmatically to Service.getPort() or specified via annotations)? I guess we'll be required to support these eventually as part of JAX-WS 2.1 conformance. Cheers, Eoghan > - Dan > > On 4/20/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > > > > > > 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 > > > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
