Dan Diephouse wrote:
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.
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
