cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Selecting an Outbound Policy Alternative [Re: svn commit: r531684...]
Date Wed, 25 Apr 2007 18:29:15 GMT
Dan Diephouse wrote:

> On 4/25/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
>>
>> dandiep@apache.org wrote:
>>
>> >Author: dandiep
>> >Date: Mon Apr 23 19:30:43 2007
>> >New Revision: 531684
>> >
>> >URL: http://svn.apache.org/viewvc?view=rev&rev=531684
>> >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
> now.
>
> 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.

Defensive coding in the interceptors is one way- and a good idea anyway. 
E.g. in the addressing interceptors handleMessage is a no-op if there 
are no addressing headers/decoded addressing properties in the message.
Make the behaviour of the policy framework w.r.t eager/deferred policy 
alternative selection configurable.
Getting the assertion providers more involved in the selection of the 
alternative is another way.

>
> 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?
>
Yes, I think that's fine for now - and also longterm  as we don't want 
to re-implement the wheel as far as policy attachment is concerned.

> 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?

Yes it does - I did not know that there was a ServiceModelPolicyProvider 
already - that's exactly what I was missing and was thinking about 
implementing.

Andrea.

>
> Cheers,
> - Dan
>
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>


Mime
View raw message