It sounds like the two things could be complimenterary. I see WSFeatures supplementing the policy framework in the following ways:
* WSFeatures can ensure that all the pre-requisites are around - like the policy interceptors or possibly the SAAJ*Interceptors in the case of WS-Security. * WSFeatures can customize a client/server/bus if it needs to (which isn't easily done via an interceptor) * They can also provide configuration values that doesn't require WS-Policy. I think WS-Policy is great for a lot of things, especially where Policy schemas already exist, but do we really want to configure *everything* via Policy? My reaction is no. * From an API perspective it is much easier to work with a bean like FooWSFeature as opposed to creating a Policy document by hand. I don't think we want to force users to construct policy documents. * Less overhead if ws-policy isn't needed I concur that we don't want two ways to do the same thing, but these don't seem like the same thing to me after some analysis. Cheers, - Dan On 3/23/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
Hi Dan, Dan Diephouse wrote: > Seeing that I read Eoghan's message after yours.... just wanted to > clarify > that if the ws policy layer can install things, we may want to add > support > for embedding policy expressions directly. Yes - see how easy (practically non-existent) the configuration of the Addressing and rm features is in the system tests in the org.apache.cxf.systest.ws.policy package. Having said that it does require the presence of the policy interceptors themselves (and there is a bunch of them), but these can be auto-installed at bus level by setting one boolean property, see the cfg files for the above mentioned system tests. BTW the policy interceptors do nothing if no policies used, but they'd have to come to that detect that first of all, which is an overhead we may want to avoid, and the reason why the policy interceptors are not installed by default. > My two main concerns are > 1. WS-Policy isn't expressive enough for all configurations. For > instance, > ws-securitypolicy isn't sufficient for ws-security configuration as I > understand. I still need to supply my keys and what not via some other > directives. > 2. There isn't a WS-Policy schema for everything. I agree. My primary concern is about using the same data types and functionality, where possible For example, a jaxws-rm feature should have a child element of type RMAssertion, and the implementation of the feature would simply delegate to the policy framework by a) translating the presence of the jaxws-rm feature bean into the presence of an RMAssertion included in a policy attached to the endpoint (we may have move some policy APIs into the api module for that) and b) ensuring that the policy framework interceptors are installed (the equivalent of setting the "registerInterceptors" attribute on the PolicyEngine to true). Other ws-features may have to do more work and may not be able to delegate to the policy framework. They would install feature specific interceptors themselves. Cheers, Andrea. > > Thoughts? > - Dan > > On 3/22/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > >> >> Hi Andrea, >> >> >> On 3/20/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: >> > >> > >> > What is the connection between the <wsrm:reliability> element and the >> > RMAssertion? Is the timeout attribute in <wsrm:reliability> element >> > synonymous with the InactivityTimeout in the RMAssertion? >> > I would like to see the above way of configuring WS-* features in sync >> > with the configuration of these features as envisaged in their resp. >> > specs, both at the data level ( i.e. reuse of the RMAssertion type for >> > example) and for aggregation purposes (use WS-Policy to specify >> > optionalities, requirements, express alternatives etc.). >> >> >> >> Don't take my <wsrm:reliability> as a specific proposal for WS-RM >> configuration syntax. I think we should continue to use the RM policy >> type >> which you've been using. >> >> >> Why not allow <wsp:Policy >> > xmlns:wsp=" http://www.w3.org/2006/07/ws-policy";> child elements in >> > <jaxws:client>? >> >> >> The benefit is that a FooWSFeature class has an opportunity to configure >> the Client/Bus/Server. This means that a user won't have to add all the >> interceptors themselves, the WSFeature can just take care of it. I agree >> that we should reuse the Policy configuration wherever possible. >> >> BTWwhat is actually jaxws specific about these features - or the >> > client/conduit injection for that matter? It should be possible to >> > inject a conduit into any kind of client (and configure its WS-* >> > features) - JAXWS or not. >> > >> > JAX-WS 2.1 introduced the concept of WSFeature classs (I think that >> was >> the name at least). I want to figure out what is in that spec so they >> can >> align nicely. However, all the javadocs/specs have been pulled >> temporarily >> so I can't really check to see what is going on there. >> >> Cheers, >> - Dan >> >> >> -- >> Dan Diephouse >> Envoi Solutions >> http://envoisolutions.com | http://netzooid.com/blog > > > > >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
