cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 16:25:09 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 20 April 2007 16:59
> To: cxf-dev@incubator.apache.org
> 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 <eoghan.glynn@iona.com> 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:dan@envoisolutions.com]
> > > Sent: 20 April 2007 08:23
> > > To: cxf-dev@incubator.apache.org
> > > 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
> 

Mime
View raw message