cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 16:59:47 GMT

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" <>
To: <>
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 <> 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
> |
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message