cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Selecting an Outbound Policy Alternative [Re: svn commit: r531684...]
Date Thu, 26 Apr 2007 14:44:55 GMT
>
> >
> >
> > 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.
>

Good ideas. Along those lines, it'd be cool if an inbound policy that was
not met could be ruled out automatically as a possibility for the outbound
chain. For instance, say we have a policy that says "you must use HTTPS or
you must use WS-Security for this service" If a person sends a message over
HTTPS, that would mean we can rule out right away that second policy as a
possibility.

The tricky part would seem to be that the inbound/outbound policy can differ
because we can attach policies to specific messages. But if we could work
out a way to rule out specific policies for the outbound chain based on the
inbound behavior/assertions met, I think that would probably help a lot of
things. Thoughts?

- Dan

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

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