You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/04/20 09:23:06 UTC
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
Re: Some quick thoughts on WSFeature and Policies
Posted by Polar Humenn <ph...@iona.com>.
Dan Diephouse wrote:
> [snip]
> 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() { .. }
>
Heh heh, this CXF thing is becoming more and more like a CORBA ORB. :^)
I certainly agree with this approach.
Cheers,
-Polar
> 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
>
Re: Some quick thoughts on WSFeature and Policies
Posted by Andrea Smyth <an...@iona.com>.
Dan Diephouse wrote:
> Re #1 - Couldn't sleep last night, so what you got instead was a tome on
> configuration and policy!
>
> Both form support schema based configuration - WS-Policy vs Spring XML.
> However the WSFeature stuff also allows the more flexible Spring <bean>
> based approach.
>
> With the WS-Policy scenario what happens is you first write your schema.
> Then you write interceptors which get inserted into the chain when your
> policy assertion is active. This interceptor reads the policy the user
> asserted and use it to configure future interceptors.
This is not the case for RM or addressing. No additional interceptors
were written - instead the existing rm and addressing interceptors were
modified to
a) retrieve the effective policy
b) exhibit operation and message type specific behaviour (previously
only endpoint specific or global) and confirm wether or not they were
able to do so.
The ability to apply features on a more granular basis than
service/endpoint is what distinguishes the WS-Policy approach from the
all our Spring based configuration approaches - whether they use
WSFeature beans or not.
Andrea.
>
> With the WSFeature scenario you would first write your WSFeature bean.
> This
> could have various properties (keystores, policies, schema generated
> config
> types, other beans, etc). To enable nice XML you would have to write a
> Spring namespace handler (or preferrably use a default one that does the
> mapping automagically for you). Otherwise you can fall back to the <bean>
> based approach. You could also use the WSFeature easily via the API with
> Server/clientfactorybeans. (This could potentially be easy with
> ws-policy as
> well. I'm not sure if this is just missing at the moment or I haven't
> seen
> it yet)
>
> Does that make sense?
>
> - Dan
>
> On 4/20/07, Fred Dushin <fr...@dushin.net> wrote:
>
>>
>> Hi Dan,
>>
>> Question 1. Are you the 5th cylon? I don't think cylons sleep :)
>>
>> Not sure how this addresses your question, but I'd like to mention
>> something about your WS-Security example.
>>
>> First, I agree that there is a gap in WS-SecurityPolicy when it comes
>> to the specification of key material or user information (such as a
>> name or password); that typically is "left to the implementation".
>>
>> But I want to make sure that the WS-Feature approach you are talking
>> about doesn't tie us down to schema-generated types, when it comes to
>> programmatic configuration of features. For example, you have some
>> example code:
>> > 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>
>>
>> (and equivalently with your policy snippet)
>>
>> Does this mean that I would be limited, in my feature.setTrustKeyStore
>> (...) operation to passing in a string, e.g., a file path to a
>> keystore on disk, or (recursively), a schema-generated struct that
>> contains a string?
>>
>> I have a real problem with that approach, which I can illustrate with
>> an anecdote. It turns out that Apple, for example, ships a Keystore
>> implementation that provides a front-end to the user's KeyChain --
>> this is a place to *securely* place keys, passwords, notes --
>> whatever you want, really. But the thing about this is, you don't
>> load the keystore off the file system -- you get to it through
>> operating system calls. But all of the ugly nitty gritty details
>> about how this is done are hidden by the keystore implementation. As
>> a Java programmer, you just to a Keystore.getInstance() with the
>> right parameters. I presume Windows users have similar access their
>> user-level keys and certificates.
>>
>> So this is a case-in-point where you might have a POJO you want to
>> use to initialize a feature, as it were -- as aI suspect there are
>> others. I don't know enough about our code generators to know if you
>> can put a POJO on a schema-generated type without violating any
>> implicit contracts. Maybe you can, maybe you can't. Maybe the fact
>> that you can now is an implementation detail that will change in the
>> future. (If anyone knows the answers to these questions, please
>> advise!)
>>
>> So that's the only constraint I would like to see on WS-Features --
>> the ability to use POJOs with them, and not to be forced down to the
>> LCD that is XML schema.
>>
>> -Fred
>>
>
>
>
Re: Some quick thoughts on WSFeature and Policies
Posted by Fred Dushin <fr...@dushin.net>.
Yes it makes sense, but I don't think it addresses the concern that I
expressed in my email, to wit, that we are kowtowing to XML, as the
least common denominator for programmatic configuration of behavior.
Again, UNLESS you can safely put POJOs on schema-generated types.
If we can get around that obstacle (and I really do think it's an
obstacle -- not just a "nice to have"), then I'd be happier with the
approach.
-Fred
On Apr 20, 2007, at 12:29 PM, Dan Diephouse wrote:
> With the WSFeature scenario you would first write your WSFeature
> bean. This
> could have various properties (keystores, policies, schema
> generated config
> types, other beans, etc). To enable nice XML you would have to write a
> Spring namespace handler (or preferrably use a default one that
> does the
> mapping automagically for you). Otherwise you can fall back to the
> <bean>
> based approach. You could also use the WSFeature easily via the API
> with
> Server/clientfactorybeans. (This could potentially be easy with ws-
> policy as
> well. I'm not sure if this is just missing at the moment or I
> haven't seen
> it yet)
>
> Does that make sense?
Re: Some quick thoughts on WSFeature and Policies
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I'm not it sure whether it can help this dicussion or not, but IMHO it would be better if WS-Policy was not considered as a configuration mechanism equal to other ones. IMHO the main reason the service uses WS-Policy assertions is to tell the outside world what is it that the client needs to be able to do/know in order to succeed in consuming this service, let the client choose the right service through the intersection, etc. WS-Policy assertion is good if it's understood by both the consumer and the provider.
The sideeffect for the service is that these WS-Policy assertions might (or might not) help to configure the service somehow along the way, but that's not the goal of the WS-Policy per se, to configure the service.
So IMHO if, one exposes the WS-Policy assertion then its primary goal should be help the client; if, by doing so, one can configure the service along the way, then it's fine, and if not then let some other mechanisms to complete the related configuration.
For ex, lets take one of the WS-Security policy assertions as an example. It's meant to be attached to one of the attachment points inside the WSDL. The main goal here is to tell the client how it needs to, say, secure a given message. It's not a limitation of this security assertion in that it doesn't bootstrap the service with the related key material config, simply because this is not what this assertion was created for. So the bootstrapping can be completed through some other mechanisms.
Cheers, Sergey
----- Original Message -----
From: "Dan Diephouse" <da...@envoisolutions.com>
To: <cx...@incubator.apache.org>
Sent: Friday, April 20, 2007 5:29 PM
Subject: Re: Some quick thoughts on WSFeature and Policies
> Re #1 - Couldn't sleep last night, so what you got instead was a tome on
> configuration and policy!
>
> Both form support schema based configuration - WS-Policy vs Spring XML.
> However the WSFeature stuff also allows the more flexible Spring <bean>
> based approach.
>
> With the WS-Policy scenario what happens is you first write your schema.
> Then you write interceptors which get inserted into the chain when your
> policy assertion is active. This interceptor reads the policy the user
> asserted and use it to configure future interceptors.
>
> With the WSFeature scenario you would first write your WSFeature bean. This
> could have various properties (keystores, policies, schema generated config
> types, other beans, etc). To enable nice XML you would have to write a
> Spring namespace handler (or preferrably use a default one that does the
> mapping automagically for you). Otherwise you can fall back to the <bean>
> based approach. You could also use the WSFeature easily via the API with
> Server/clientfactorybeans. (This could potentially be easy with ws-policy as
> well. I'm not sure if this is just missing at the moment or I haven't seen
> it yet)
>
> Does that make sense?
>
> - Dan
>
> On 4/20/07, Fred Dushin <fr...@dushin.net> wrote:
>>
>> Hi Dan,
>>
>> Question 1. Are you the 5th cylon? I don't think cylons sleep :)
>>
>> Not sure how this addresses your question, but I'd like to mention
>> something about your WS-Security example.
>>
>> First, I agree that there is a gap in WS-SecurityPolicy when it comes
>> to the specification of key material or user information (such as a
>> name or password); that typically is "left to the implementation".
>>
>> But I want to make sure that the WS-Feature approach you are talking
>> about doesn't tie us down to schema-generated types, when it comes to
>> programmatic configuration of features. For example, you have some
>> example code:
>>
>> > 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>
>>
>> (and equivalently with your policy snippet)
>>
>> Does this mean that I would be limited, in my feature.setTrustKeyStore
>> (...) operation to passing in a string, e.g., a file path to a
>> keystore on disk, or (recursively), a schema-generated struct that
>> contains a string?
>>
>> I have a real problem with that approach, which I can illustrate with
>> an anecdote. It turns out that Apple, for example, ships a Keystore
>> implementation that provides a front-end to the user's KeyChain --
>> this is a place to *securely* place keys, passwords, notes --
>> whatever you want, really. But the thing about this is, you don't
>> load the keystore off the file system -- you get to it through
>> operating system calls. But all of the ugly nitty gritty details
>> about how this is done are hidden by the keystore implementation. As
>> a Java programmer, you just to a Keystore.getInstance() with the
>> right parameters. I presume Windows users have similar access their
>> user-level keys and certificates.
>>
>> So this is a case-in-point where you might have a POJO you want to
>> use to initialize a feature, as it were -- as aI suspect there are
>> others. I don't know enough about our code generators to know if you
>> can put a POJO on a schema-generated type without violating any
>> implicit contracts. Maybe you can, maybe you can't. Maybe the fact
>> that you can now is an implementation detail that will change in the
>> future. (If anyone knows the answers to these questions, please
>> advise!)
>>
>> So that's the only constraint I would like to see on WS-Features --
>> the ability to use POJOs with them, and not to be forced down to the
>> LCD that is XML schema.
>>
>> -Fred
>>
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Some quick thoughts on WSFeature and Policies
Posted by Dan Diephouse <da...@envoisolutions.com>.
Re #1 - Couldn't sleep last night, so what you got instead was a tome on
configuration and policy!
Both form support schema based configuration - WS-Policy vs Spring XML.
However the WSFeature stuff also allows the more flexible Spring <bean>
based approach.
With the WS-Policy scenario what happens is you first write your schema.
Then you write interceptors which get inserted into the chain when your
policy assertion is active. This interceptor reads the policy the user
asserted and use it to configure future interceptors.
With the WSFeature scenario you would first write your WSFeature bean. This
could have various properties (keystores, policies, schema generated config
types, other beans, etc). To enable nice XML you would have to write a
Spring namespace handler (or preferrably use a default one that does the
mapping automagically for you). Otherwise you can fall back to the <bean>
based approach. You could also use the WSFeature easily via the API with
Server/clientfactorybeans. (This could potentially be easy with ws-policy as
well. I'm not sure if this is just missing at the moment or I haven't seen
it yet)
Does that make sense?
- Dan
On 4/20/07, Fred Dushin <fr...@dushin.net> wrote:
>
> Hi Dan,
>
> Question 1. Are you the 5th cylon? I don't think cylons sleep :)
>
> Not sure how this addresses your question, but I'd like to mention
> something about your WS-Security example.
>
> First, I agree that there is a gap in WS-SecurityPolicy when it comes
> to the specification of key material or user information (such as a
> name or password); that typically is "left to the implementation".
>
> But I want to make sure that the WS-Feature approach you are talking
> about doesn't tie us down to schema-generated types, when it comes to
> programmatic configuration of features. For example, you have some
> example code:
>
> > 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>
>
> (and equivalently with your policy snippet)
>
> Does this mean that I would be limited, in my feature.setTrustKeyStore
> (...) operation to passing in a string, e.g., a file path to a
> keystore on disk, or (recursively), a schema-generated struct that
> contains a string?
>
> I have a real problem with that approach, which I can illustrate with
> an anecdote. It turns out that Apple, for example, ships a Keystore
> implementation that provides a front-end to the user's KeyChain --
> this is a place to *securely* place keys, passwords, notes --
> whatever you want, really. But the thing about this is, you don't
> load the keystore off the file system -- you get to it through
> operating system calls. But all of the ugly nitty gritty details
> about how this is done are hidden by the keystore implementation. As
> a Java programmer, you just to a Keystore.getInstance() with the
> right parameters. I presume Windows users have similar access their
> user-level keys and certificates.
>
> So this is a case-in-point where you might have a POJO you want to
> use to initialize a feature, as it were -- as aI suspect there are
> others. I don't know enough about our code generators to know if you
> can put a POJO on a schema-generated type without violating any
> implicit contracts. Maybe you can, maybe you can't. Maybe the fact
> that you can now is an implementation detail that will change in the
> future. (If anyone knows the answers to these questions, please
> advise!)
>
> So that's the only constraint I would like to see on WS-Features --
> the ability to use POJOs with them, and not to be forced down to the
> LCD that is XML schema.
>
> -Fred
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Some quick thoughts on WSFeature and Policies
Posted by Fred Dushin <fr...@dushin.net>.
Hi Dan,
Question 1. Are you the 5th cylon? I don't think cylons sleep :)
Not sure how this addresses your question, but I'd like to mention
something about your WS-Security example.
First, I agree that there is a gap in WS-SecurityPolicy when it comes
to the specification of key material or user information (such as a
name or password); that typically is "left to the implementation".
But I want to make sure that the WS-Feature approach you are talking
about doesn't tie us down to schema-generated types, when it comes to
programmatic configuration of features. For example, you have some
example code:
> 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>
(and equivalently with your policy snippet)
Does this mean that I would be limited, in my feature.setTrustKeyStore
(...) operation to passing in a string, e.g., a file path to a
keystore on disk, or (recursively), a schema-generated struct that
contains a string?
I have a real problem with that approach, which I can illustrate with
an anecdote. It turns out that Apple, for example, ships a Keystore
implementation that provides a front-end to the user's KeyChain --
this is a place to *securely* place keys, passwords, notes --
whatever you want, really. But the thing about this is, you don't
load the keystore off the file system -- you get to it through
operating system calls. But all of the ugly nitty gritty details
about how this is done are hidden by the keystore implementation. As
a Java programmer, you just to a Keystore.getInstance() with the
right parameters. I presume Windows users have similar access their
user-level keys and certificates.
So this is a case-in-point where you might have a POJO you want to
use to initialize a feature, as it were -- as aI suspect there are
others. I don't know enough about our code generators to know if you
can put a POJO on a schema-generated type without violating any
implicit contracts. Maybe you can, maybe you can't. Maybe the fact
that you can now is an implementation detail that will change in the
future. (If anyone knows the answers to these questions, please
advise!)
So that's the only constraint I would like to see on WS-Features --
the ability to use POJOs with them, and not to be forced down to the
LCD that is XML schema.
-Fred
Re: Some quick thoughts on WSFeature and Policies
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 4/23/07, Glynn, Eoghan <eo...@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
RE: Some quick thoughts on WSFeature and Policies
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----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)?
> > 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.
Cheers,
Eoghan
> With JAX-WS you can do something like this
>
> @WebService
> @WebServiceFeatures( features = { AddressingFeature.ID,
> MTOMFeature.ID, HTTPSessionFeature.ID, FastInfosetFeature.ID
> } ) public class MyWebServiceImpl { .... }
>
> The JAX-WS 2.1 RI comes with those features and several more.
> I think the first two are the only standard ones. We could
> map these back to our own WSFeature/WSPlugin representation
> pretty easily. It could probably be mapped back to policy too.
>
> BTW, one technical hurdle we have with writing policies right
> which reference the policy xsd outside the policy module is
> not possible. For instance, if I put the security policy xsd
> in the security policy module, it regenerates the core policy
> beans. To support reuse of the existing beans we have to
> migrate to JAXB 2.1. This could make a bit difficult in the
> meantime for outside people to write more advanced policies.
> Hopefully we can fix this in the 2.1 timeframe though.
>
> - Dan
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Some quick thoughts on WSFeature and Policies
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 4/20/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
> > 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.
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.
> 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. With
JAX-WS you can do something like this
@WebService
@WebServiceFeatures( features = { AddressingFeature.ID, MTOMFeature.ID,
HTTPSessionFeature.ID, FastInfosetFeature.ID } )
public class MyWebServiceImpl { .... }
The JAX-WS 2.1 RI comes with those features and several more. I think the
first two are the only standard ones. We could map these back to our own
WSFeature/WSPlugin representation pretty easily. It could probably be mapped
back to policy too.
BTW, one technical hurdle we have with writing policies right which
reference the policy xsd outside the policy module is not possible. For
instance, if I put the security policy xsd in the security policy module, it
regenerates the core policy beans. To support reuse of the existing beans we
have to migrate to JAXB 2.1. This could make a bit difficult in the meantime
for outside people to write more advanced policies. Hopefully we can fix
this in the 2.1 timeframe though.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Some quick thoughts on WSFeature and Policies
Posted by Andrea Smyth <an...@iona.com>.
Dan Diephouse wrote:
> Re: #4 - do we have a way to do programmatic policy manipulation that
> isn't
> associated with transports? i.e. what would be the recommended way to
> assert
> a RMAssertion on my service via the API?
1. all manually:
RMInInterceptor rmIn = new RMInInterceptor();
Bus.getInInterceptors().add(rmIn);
...
Bus.getExtension(RMManager.class).getRMAssertion().setBaseRetransmissionInterval(...)
;
The latter applies of course to all services - but it's possible to
programatically change that by creating a service specific RMManager,
and using service specific rm interceptors.
2. programatically attach a policyElement to wsdl:
org.apache.neethi.Policy p = new Policy();
org.apache.neethi.Assertion a = new
org.apache.cxf.ws.policy.JaxbAsertion<RMAssertion>();
p.addPolicyComponent(a);
... getServiceInfo().addExtensor(new Policy);
3. programming an external attachment provider (I won't go into details
here, but that also can be done in a couple of lines).
Andrea.
>
> Also, I would classify WSFeatures as a part of the Spring bean
> configurations, since they're essentially part of the
> *ServerFactory/*ClientFactory classes IMO.
>
> - Dan
BTW why restrict this to WSFeatures -
>
> On 4/20/07, Glynn, Eoghan <eo...@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
>> >
>>
>
>
>
RE: Some quick thoughts on WSFeature and Policies
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----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 <eo...@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
>
Re: Some quick thoughts on WSFeature and Policies
Posted by Dan Diephouse <da...@envoisolutions.com>.
Re: #4 - do we have a way to do programmatic policy manipulation that isn't
associated with transports? i.e. what would be the recommended way to assert
a RMAssertion on my service via the API?
Also, I would classify WSFeatures as a part of the Spring bean
configurations, since they're essentially part of the
*ServerFactory/*ClientFactory classes IMO.
- Dan
On 4/20/07, Glynn, Eoghan <eo...@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
RE: Some quick thoughts on WSFeature and Policies
Posted by "Glynn, Eoghan" <eo...@iona.com>.
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
>