You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/03/22 21:58:06 UTC
FooWSFeature [was Re: [PROPOSAL] Client and Conduit changes]
Hi Andrea,
On 3/20/07, Andrea Smyth <an...@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
Re: FooWSFeature [was Re: [PROPOSAL] Client and Conduit changes]
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <an...@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 <da...@envoisolutions.com> wrote:
> >
> >>
> >> Hi Andrea,
> >>
> >>
> >> On 3/20/07, Andrea Smyth <an...@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
Re: FooWSFeature [was Re: [PROPOSAL] Client and Conduit changes]
Posted by Andrea Smyth <an...@iona.com>.
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 <da...@envoisolutions.com> wrote:
>
>>
>> Hi Andrea,
>>
>>
>> On 3/20/07, Andrea Smyth <an...@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
>
>
>
>
>
Re: FooWSFeature [was Re: [PROPOSAL] Client and Conduit changes]
Posted by Dan Diephouse <da...@envoisolutions.com>.
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. 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.
Thoughts?
- Dan
On 3/22/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> Hi Andrea,
>
>
> On 3/20/07, Andrea Smyth <an...@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