cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Some quick thoughts on WSFeature and Policies
Date Mon, 23 Apr 2007 13:50:07 GMT
On 4/23/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 20 April 2007 17:40
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Some quick thoughts on WSFeature and Policies
> >
> > > 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.
> >
> >
> > Totally agreed. I'm just trying to figure out how to best
> > support the various use cases.
> >
> > At the very least I think I'd like a way to embed a policy
> > inside an <endpoint>/<client> without resorting to an attachment.
>
>
> Just so I understand, would embedding a policy in this way be:
>
> (a) a straight *alternative* to attaching the policy externally, so that
> the attachement is no longer required to cause the corresponding
> capability to be enabled
>
> or
>
> (b) more of a "complete the picture" sort of idea ... e.g. a feature
> that refers to a policy asserted elsewhere, and additionally provides
> some extra detail not expressed in the policy itself (such as the
> keystore location & password in the case of a security policy)?


So the way I ended up implementing it is like (b) I think. The Feature can
supply stuff thats not in the policy. Then the PolicyFeature will supply an
inline policy so an attachment is no longer needed. This allows us to use
straight-up Policy whenever possible. But if someone needs to supply more
details or customize the Client/Server/Bus, as in the WS-Security case, then
they can write their own feature class instead of just a
PolicyInterceptorProvider.

To take a more concrete example, right now WSRM can be completely configured
via Policy. But say we add a database store at somepoint. I would see that
being configured via a RMFeature.

One advantage of this is that it allows you to seperate your configuration
from policy if necessary. For instance, I could configure one WS-Security
feature with the various keystores and then have different policies for each
service.

> > 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.
> >
> >
> > They're similar - which is why I'm thinking of renaming them
> > plugins.
>
>
> +1 for renaming to avoid confusion with JAX-WS 2.1 WebServiceFeatures.
>
> However I'm not sure about "plugin", which to me has connotations of "a
> coarse-grain blob of functionality which may be optionally loaded into
> the container/Bus/whatever". For example a "security plugin" or "routing
> plugin".
>
> Sounds like these features are more fine-grained and concerned with
> detailed settings, as opposed to the life-cycle issues around
> dynamically loading a plugin. Anyway, just my two cents.


Yeah, I agree. I don't have any better names though - "Options"? I settled
on AbstractFeature for the moment.

Cheers,
- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message