cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Selecting an Outbound Policy Alternative [Re: svn commit: r531684...]
Date Wed, 25 Apr 2007 18:05:44 GMT
On 4/25/07, Andrea Smyth <> wrote:
> wrote:
> >Author: dandiep
> >Date: Mon Apr 23 19:30:43 2007
> >New Revision: 531684
> >
> >URL:
> >Log:
> >o CXF-593: MTOM Policy support from Chris Moesel with a few slight
> modifications
> >o Changed the PolicyVerificationOutInterceptor to check assertions using
> the
> >  EffectivePolicy (and hence select the most appropriate policy) instead
> of
> >  doing an arbitrary check() on the first policy available.
> >
> >
> Hi Dan,
> This was not an arbitrary check on the 'first policy available' but on a
> previously chosen alternative.
> There is only ever one policy - at least on the outbound paths where we
> know message and operation type for the underlying message, but this
> could have several alternatives. Although this would be unusual, the
> effective policy could be:
> <wsp:Policy>
>     <wsp:ExactlyOne>
>         <wsp:All>
>            <mtom:OptimizedMimeSerialization>
>         </wsp:All>
>         <wsp:All>
>             <wsam:Addressing>
>                 <wsp:Policy ...>
>             <wsam:Addressing>
>         </wsp:All>
>     </wsp:ExactlyOne>
> <wsp:Policy>
> meaning that to support one of the alternatives we need either the
> addressing interceptors or the mtom interceptor on the path, but not both.
> There are two options now:
> a) The policy framework chooses the alternative upfront, installs only
> one set of interceptors. In that case it only needs to verify at the end
> of the chain that all assertions in the chosen alternative have indeed
> been asserted (the addressing interceptors may have failed in asserting
> the addressing assertion depending on the content of the nested Policy).
> b) The other option is to defer the choice and add both addressing and
> mtom interceptors (in general: interceptors for all assertions types
> occurring in any of the alternatives), and then check if there is one
> alternative for which all assertions have been asserted (this is the way
> it is done on the inbound paths on client and server side).
> The advantage of a) is that limiting the number of interceptors is
> beneficial to performance (e.g. no encoding/decoding of headers).
> The advantage of b) is that we maximise the chances that the message's
> effective policy is supported.

Ahhh, this explanation makes the code that was there make much more sense

If this merge is intended to use b) instead of a) then it is incomplete
> as the initialisation phase in EffectivePolicyImpl (calculate effective
> policy, choose one of its alternatives, determine interceptors) needs to
> be changed accordingly. getChosenAlternative() becomes meaningless and
> should be removed from API and implementation.
> Also, if the EffectivePolicy object is added to the message in
> ClientPolicyOutInterceptor and ServerPolicyOutInterceptor then it should
> also be added in ServerPolicyOutFaultInterceptor.

If not, then what are the intentions instead?  As it stands the effects
> are rather limited - they are not a solution to the problem brought up
> in the discussion about the MTOM interceptor's need to know if a given
> MTOM assertion is optional.

So my intentions were to ensure that we could defer the selection of the
policy as you describe in (b). For MTOM this had unique effect of not
breaking things because the incoming set the mtom-enabled property. Which
could be considered the equivalent of the addressing in interceptors
enabling the addressing outbound interceptors.

This is indeed a most difficult problem. I don't really have any great
suggestions offhand on how to fix this though. I'll confess I'm not a huge
fan of (a) because the preferred policy on the outgoing side may affect the
outbound policy. For instance, if someone sends an MTOM message, I want to
respond with MTOM. Or if someone sends a message with addressing headers, I
want to respond with addressing headers. However I see all the problems with
(b) that you see as well!

What are your thoughts? I'd like to maybe poke around a bit more
today/tomorrow and see if anything hits me on how to fix this.

Regarding the WSPolicyFeature: How are they hooked up with the Policy
> Framework?

The <Policy> document embedded in the Spring XML files is used to create a
Policy object and then attached to the ServiceInfo. The
ServiceModelPolicyProvider then supplies the policies off from the
ServiceInfo/Operation/Binding for the policy layer.

>From what I can see they use the AssertionBuilders to parse
> child elements and enable the framework. But that alone does not have
> much effect. In particular, no interceptors will get added when a
> message targeted at that endpoint is processed. For that to happen the
> policy framework needs to make the connection between the policy and a
> policy subject (service, endpoint, operation, message). Clearly there is
> an implied association here between the Policies in a WSFeature and the
> endpoint to which this feature applies.

Currently, there is no support for embedding policy inside spring files and
applying them to more fine grained subjects - operations, messages, etc. We
could create a custom syntax for this, but at this point, maybe its just
easier to embed it within your WSDL?

But how should these Policy - (endpoint) subject associations be
> reconciled with other, possibly more fine grained associations, to
> operation or message  subjects?  Or with the association between another
> Policy and the service subject?

To me the obvious answer would seem to treat them  in just the same way
> as Policies attached to elements in the underlying wsdl or Policies in
> matching PolicyAttachment,  i.e. to combine (merge) them with other
> Policies applying to the same subject and to other subjects within the
> same scope. If  there are no objections that's what I will do.

 I thought the Policy framework already took care of this via merging the
Policies from the PolicyProviders insinde PolicyEngineImpl?

- Dan

Dan Diephouse
Envoi Solutions |

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