Steven E. Harris wrote:
Andrea Smyth <[EMAIL PROTECTED]> writes:
There several ways to do this:
Thank you for your very detailed reply.
1. Using WS-Policy:
Enable the policy framework (by setting the "enabled" attribute of the
PolicyEngine to true) and making sure that a Policy with an Addressing
assertion is attached to the WSDL service, port, portType or interface
(see cfg file addr.xml for system test
org.apache.cxf.systest.ws.policy.AddressingPolicyTest)
I wound up getting this to work using an inline policy in my WSDL
file. What confused me is the wsp:Optional attribute. If I indicate
that the wsam:Addressing assertion is optional, the client never sends
the addressing headers. Is there some way for the server to indicate
the headers are optional (be it in WSDL or as an attachment), but
still control whether or not the client sends the addressing headers?
No, because: a)
<wsp:Policy>
<wsam:Addressing wsp:Optional="true">
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>
is equivalent to:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false">
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
<wsp:All/>
</wsp:ExactlyOne>
</wsp:Policy>
and b) choosing the alternative is entirely up to the policy framework -
in particular it does not involve the assertion providers. It simply
chooses the first alternative that it sees can potentially be supported
- and that can be the empty alternative.
What do you mean with controlling whether or not the client sends the
addressing headers? Who, e.g. what interceptor or other component should
exert that control and when?
Right now, your only option is to use a different wsdl on the client
side (with a different Policy).
Long term, we need to make the policy framework's strategy of choosing
an altermative more predicatable (considering that there is no order
implies in between different alternatives this is practically
unpredictable at the moment). I can imagine the following criteria:
1) the alternative with the least number of assertions
2) the alternative with the maximum number of assertions
3) cheapest alternative - needs involvement of the assertion providers
1) or 2) are relatively can be implemented easily.
Come to think of it, the client side alternative selection strategy
should be changed to 1) as the default and 2) as 2) as optional
alternative ASAP. I'll see I can get around to doing it tomorrow.
2. Using CXF Features:
This is relatively new, and I don't know much about them, but see cfg
file addr-inline-policy.xml for system test
org.apache.cxf.systest.ws.policy.AddressingInlinePolicyTest
I'm looking into this one today. I see that the addressing policy is
attached to an endpoint via the jaxws:features element. Two questions:
o Does this style of policy specification also require definition of
the bean with id org.apache.cxf.ws.policy.PolicyEngine of class
org.apache.cxf.ws.policy.spring.InitializingPolicyEngine?
No, the feature is implemented in such a way that it rertieves the
policy engine and enables it if is not enabled yet.
o How can we find out what all the possible features are that can be
bound in this manner?
Do you mean with the WSPolicyFeature? You can use the same set of
Assertions as you would otherwise in WSDL or attachments, in other words
you need an AssertionBuilder registered (or fail with a PolicyException
straight away). See the CXF User's Guide for the list of assertion types
that CXF supports out of the box.
Andrea.
