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
