cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 07:23:06 GMT
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

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