cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: FooWSFeature [was Re: [PROPOSAL] Client and Conduit changes]
Date Mon, 26 Mar 2007 02:11:11 GMT
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 <andrea.smyth@iona.com> 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 <dan@envoisolutions.com> wrote:
> >
> >>
> >> Hi Andrea,
> >>
> >>
> >> On 3/20/07, Andrea Smyth <andrea.smyth@iona.com> 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

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