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 <[EMAIL PROTECTED]> 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
