On 4/25/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] 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. 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? Cheers, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
