You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2010/07/21 20:50:01 UTC
Re: WS-Policy is not applied to the outbound message on the server side (WSDL first)
Sergey,
Not sure what would cause this. My suggestion would be to stick a breakpoint
at the end of the PolicyIn and Out interceptor's handleMessage calls and have
it print the interceptor chain. If the RM policy is enabled, it SHOULD have
added the RM interceptors. That would at least tell you if it's a policy
issue or an RM issue.
Dan
On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> Hi
>
> I'm looking into the following issue.
> WSDL fragment :
>
> <wsdl:binding name="SimpleServiceSoapBinding" type="tns:SimpleService">
> <wsp:Policy>
> <wswa:UsingAddressing xmlns:wswa="
> http://www.w3.org/2006/05/addressing/wsdl"/>
> <wsrmp:RMAssertion xmlns:wsrmp="
> http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> </wsp:Policy>
> </wsdl:binding>
>
> When the client invokes a simple echo() operation, the following is
> happening on the wire :
>
> 1. WS-RM CreateSequence request is sent and a successful response
> containing the sequence id/etc is sent back
> 2. Actual echo() request is sent with WS-A and WSRM headers included
>
> However the server replies with no WS-A/WS-RM headers and thus a runtime
> policy verification fails on the client side.
>
> Note that no Spring is used in this case.
>
> Obviously, the client recognizes that the above policy needs to be applied
> and the server initially responds well to a WS-RM only request. It appears
> though it is happening due to WS-RM interceptors installed by default on
> the server side.
>
> Question is : is it a bug that the server does not apply a policy to the
> outbound message (it is probably not even enforcing it on the inbound
> message too) in a WSDL-first with no Spring case ? Also, why the client
> does recognize the policy requirement but the server does not ?
>
> it's been awhile since I looked into the Ws-Policy code so some initial
> feedback will help :-)
>
> thanks, Sergey
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Policy is not applied to the outbound message on the server
side (WSDL first)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Please see
http://svn.apache.org/viewvc?rev=979764&view=rev
I've updated EndpointPolicyImpl to ignore Policies containing no assertions
in its updatePolicy() - called currenty from WSPolicyFeature only - I think
it is a safe update as opposed to say ignoring empty alternative altogether.
I've confirmed a corresponding JBossWS/CXF test with no Spring involved
passes with this update
Sergey
On Mon, Jul 26, 2010 at 9:17 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Dan
>
> On Mon, Jul 26, 2010 at 7:45 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Monday 26 July 2010 12:31:31 pm Sergey Beryozkin wrote:
>> > > If so, then either of those proposals would definitely change the
>> > > behavior of
>> > > things, especially on the client side. We kind of ran into this with
>> > > the TCK.
>> > >
>> > > For example, if the addressing policy is "optional", with the current
>> > > behavior, the client would not bother sending the addressing headers.
>> > > Doing
>> > > the addressing stuff slows things down so choosing the "empty"
>> > > alternative is
>> > > a good thing.
>> > >
>> > > I wondering if it's possible to allow the empty on outgoing on the
>> > > client, but
>> > > not on the server.
>> >
>> > that would probably be a right solution anyway given that as far as the
>> > server is concerned it has to prioritize on the non-empty alternative
>> > > Either that or we would need a new selector that somehow
>> > > would take the incoming policy into affect when calculating the
>> outgoing
>> > > policy. For example, if the addressing/rm assertions were asserted
>> on
>> > > incoming side, then chose an alternative that has those. Might be a
>> bit
>> > > more
>> > > complicated to write. Plus, the PolicyEngine would have to updated
>> to
>> > > allowing pulling the selector off the endpoint/message or similar.
>> > >
>> > > Another idea might be to have the PolicyEngine have two
>> > > AlternativeSelectors,
>> > > one for the requestor based requests that would be truely minimal and
>> one
>> > > for
>> > > the other cases that would ignore the minimal.
>> > >
>> > > For this specific issue I like the idea of restricting the server side
>> to
>> >
>> > choosing a non-empty alternative as it seems the simplest option and yet
>> > the correct one too.
>>
>>
>>
>> Not really. IMO, the "correct" thing would be to somehow compare the
>> possible
>> alternatives with the AssertionMap of the incoming request to figure out
>> which
>> alternative is "most assertable" based on the assertions of the incoming
>> request. For example, there COULD be a policy that was use "either
>> security
>> or RM". To select the correct policy on the outgoing side, you would
>> really
>> need to look at the incoming assertions.
>>
>> I don't disagree :-).
> My point is that the optionality should not affect the server side, in
> other words, if we have an optional RM policy, the server should still be
> able to enforce RM if needed. I recall that in the presence of multiple
> alternatives the server installs all the interceptors capable of dealing
> with the union of all the assertions collected from all the alternatives -
> this is not optimal but works :-). I agree the enhancement you're referring
> to would be worth spending time upon, but yes it can become very complicated
> especially in case of WS-Security policies, and nested ones in particularly.
>
>
> Ignoring an empty alternative on the server side may only have problems
> where the client indeed chose to ignore the optional policy - may be this is
> what you're referring to, but given that CXF out interceptors are usually
> well-behaved :-) (i.e if no RM/WSA in headers were present then RM/WSA out
> interceptors won't break the flow), this should probably be safe enough...
>
> I'll start investigating tomorrow where the empty alternative is coming
> from, given that no optional assertions are specified. I suspect it might be
> coming from the merge of the empty Policy with a non-empty one. May be there
> is a better and simpler fix : if we have an empty policy and a non empty one
> at a merge time then we immediately return the assertions taken from a
> non-empty one...
>
>
>
>> Unfortunately , that starts getting really complex and requires a bunch of
>> API
>> changes. :-(
>>
>> agreed :-)
>
> thanks, Sergey
>
>
>> Dan
>>
>>
>>
>>
>> >
>> > cheers, Sergey
>> >
>> > > Dan
>> > >
>> > > On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
>> > > > Hi
>> > > >
>> > > >
>> > > > after spending quite a bit of time on debugging the issue I think
>> I've
>> > > > traced where the problem is.
>> > > > Given that Policy with two assertions below we eventually get a
>> > >
>> > > normalized
>> > >
>> > > > policy, with a single ExactlyOnce and one alternative <All> with
>> those
>> > >
>> > > two
>> > >
>> > > > simple assertions inside, this is stored with EndpointPolicyImpl.
>> > > >
>> > > > Next, we get an EffectivePolicyImpl but there we end up with two
>> > > > alternative, one is a proper All with WSA & RM, another one is
>> empty.
>> > >
>> > > This
>> > >
>> > > > is not too bad but PolicyEngine in its supportsAlernative method
>> > > > returns "true" for an empty alternative such as <All/> and given
>> that
>> > > > EffectivePolicyImpl uses a MinimalSelector by default, this empty
>> > > > alternative is actually overriding a previous valid one on the basis
>> > > > that it's size (0) is less than that of the valid one.
>> > > >
>> > > > I propose two fixes :
>> > > > 1. PolicyEngine.supportsAlernative has to return false for an empty
>> > > > alternative.
>> > > > 2. MinimalSelector should ignore empty alternatives
>> > > >
>> > > > Any objections ?
>> > > >
>> > > > I'm going apply the to the snapshot and experiment if it fixes the
>> > > > issue
>> > > >
>> > > > cheers, Sergey
>> > > >
>> > > > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org>
>> wrote:
>> > > > > Sergey,
>> > > > >
>> > > > > Not sure what would cause this. My suggestion would be to stick a
>> > > > > breakpoint
>> > > > > at the end of the PolicyIn and Out interceptor's handleMessage
>> calls
>> > >
>> > > and
>> > >
>> > > > > have
>> > > > > it print the interceptor chain. If the RM policy is enabled, it
>> > >
>> > > SHOULD
>> > >
>> > > > > have
>> > > > > added the RM interceptors. That would at least tell you if
>> it's a
>> > > > > policy
>> > > > > issue or an RM issue.
>> > > > >
>> > > > > Dan
>> > > > >
>> > > > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
>> > > > > > Hi
>> > > > > >
>> > > > > > I'm looking into the following issue.
>> > > > > > WSDL fragment :
>> > > > > >
>> > > > > > <wsdl:binding name="SimpleServiceSoapBinding"
>> > >
>> > > type="tns:SimpleService">
>> > >
>> > > > > > <wsp:Policy>
>> > > > > >
>> > > > > > <wswa:UsingAddressing xmlns:wswa="
>> > > > > >
>> > > > > > http://www.w3.org/2006/05/addressing/wsdl"/>
>> > > > > >
>> > > > > > <wsrmp:RMAssertion xmlns:wsrmp="
>> > > > > >
>> > > > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
>> > > > > >
>> > > > > > </wsp:Policy>
>> > > > > >
>> > > > > > </wsdl:binding>
>> > > > > >
>> > > > > > When the client invokes a simple echo() operation, the following
>> is
>> > > > > > happening on the wire :
>> > > > > >
>> > > > > > 1. WS-RM CreateSequence request is sent and a successful
>> response
>> > > > > > containing the sequence id/etc is sent back
>> > > > > > 2. Actual echo() request is sent with WS-A and WSRM headers
>> > >
>> > > included
>> > >
>> > > > > > However the server replies with no WS-A/WS-RM headers and thus a
>> > > > > > runtime policy verification fails on the client side.
>> > > > > >
>> > > > > > Note that no Spring is used in this case.
>> > > > > >
>> > > > > > Obviously, the client recognizes that the above policy needs to
>> be
>> > > > >
>> > > > > applied
>> > > > >
>> > > > > > and the server initially responds well to a WS-RM only request.
>> It
>> > > > >
>> > > > > appears
>> > > > >
>> > > > > > though it is happening due to WS-RM interceptors installed by
>> > > > > > default on the server side.
>> > > > > >
>> > > > > > Question is : is it a bug that the server does not apply a
>> policy
>> > > > > > to the outbound message (it is probably not even enforcing it on
>> > > > > > the inbound message too) in a WSDL-first with no Spring case ?
>> > > > > > Also, why the client does recognize the policy requirement but
>> the
>> > > > > > server does not ?
>> > > > > >
>> > > > > > it's been awhile since I looked into the Ws-Policy code so some
>> > >
>> > > initial
>> > >
>> > > > > > feedback will help :-)
>> > > > > >
>> > > > > > thanks, Sergey
>> > > > >
>> > > > > --
>> > > > > Daniel Kulp
>> > > > > dkulp@apache.org
>> > > > > http://dankulp.com/blog
>> > >
>> > > --
>> > > Daniel Kulp
>> > > dkulp@apache.org
>> > > http://dankulp.com/blog
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
Re: WS-Policy is not applied to the outbound message on the server
side (WSDL first)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Dan
On Mon, Jul 26, 2010 at 7:45 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 26 July 2010 12:31:31 pm Sergey Beryozkin wrote:
> > > If so, then either of those proposals would definitely change the
> > > behavior of
> > > things, especially on the client side. We kind of ran into this with
> > > the TCK.
> > >
> > > For example, if the addressing policy is "optional", with the current
> > > behavior, the client would not bother sending the addressing headers.
> > > Doing
> > > the addressing stuff slows things down so choosing the "empty"
> > > alternative is
> > > a good thing.
> > >
> > > I wondering if it's possible to allow the empty on outgoing on the
> > > client, but
> > > not on the server.
> >
> > that would probably be a right solution anyway given that as far as the
> > server is concerned it has to prioritize on the non-empty alternative
> > > Either that or we would need a new selector that somehow
> > > would take the incoming policy into affect when calculating the
> outgoing
> > > policy. For example, if the addressing/rm assertions were asserted on
> > > incoming side, then chose an alternative that has those. Might be a
> bit
> > > more
> > > complicated to write. Plus, the PolicyEngine would have to updated
> to
> > > allowing pulling the selector off the endpoint/message or similar.
> > >
> > > Another idea might be to have the PolicyEngine have two
> > > AlternativeSelectors,
> > > one for the requestor based requests that would be truely minimal and
> one
> > > for
> > > the other cases that would ignore the minimal.
> > >
> > > For this specific issue I like the idea of restricting the server side
> to
> >
> > choosing a non-empty alternative as it seems the simplest option and yet
> > the correct one too.
>
>
>
> Not really. IMO, the "correct" thing would be to somehow compare the
> possible
> alternatives with the AssertionMap of the incoming request to figure out
> which
> alternative is "most assertable" based on the assertions of the incoming
> request. For example, there COULD be a policy that was use "either
> security
> or RM". To select the correct policy on the outgoing side, you would
> really
> need to look at the incoming assertions.
>
> I don't disagree :-).
My point is that the optionality should not affect the server side, in other
words, if we have an optional RM policy, the server should still be able to
enforce RM if needed. I recall that in the presence of multiple alternatives
the server installs all the interceptors capable of dealing with the union
of all the assertions collected from all the alternatives - this is not
optimal but works :-). I agree the enhancement you're referring to would be
worth spending time upon, but yes it can become very complicated especially
in case of WS-Security policies, and nested ones in particularly.
Ignoring an empty alternative on the server side may only have problems
where the client indeed chose to ignore the optional policy - may be this is
what you're referring to, but given that CXF out interceptors are usually
well-behaved :-) (i.e if no RM/WSA in headers were present then RM/WSA out
interceptors won't break the flow), this should probably be safe enough...
I'll start investigating tomorrow where the empty alternative is coming
from, given that no optional assertions are specified. I suspect it might be
coming from the merge of the empty Policy with a non-empty one. May be there
is a better and simpler fix : if we have an empty policy and a non empty one
at a merge time then we immediately return the assertions taken from a
non-empty one...
> Unfortunately , that starts getting really complex and requires a bunch of
> API
> changes. :-(
>
> agreed :-)
thanks, Sergey
> Dan
>
>
>
>
> >
> > cheers, Sergey
> >
> > > Dan
> > >
> > > On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
> > > > Hi
> > > >
> > > >
> > > > after spending quite a bit of time on debugging the issue I think
> I've
> > > > traced where the problem is.
> > > > Given that Policy with two assertions below we eventually get a
> > >
> > > normalized
> > >
> > > > policy, with a single ExactlyOnce and one alternative <All> with
> those
> > >
> > > two
> > >
> > > > simple assertions inside, this is stored with EndpointPolicyImpl.
> > > >
> > > > Next, we get an EffectivePolicyImpl but there we end up with two
> > > > alternative, one is a proper All with WSA & RM, another one is empty.
> > >
> > > This
> > >
> > > > is not too bad but PolicyEngine in its supportsAlernative method
> > > > returns "true" for an empty alternative such as <All/> and given that
> > > > EffectivePolicyImpl uses a MinimalSelector by default, this empty
> > > > alternative is actually overriding a previous valid one on the basis
> > > > that it's size (0) is less than that of the valid one.
> > > >
> > > > I propose two fixes :
> > > > 1. PolicyEngine.supportsAlernative has to return false for an empty
> > > > alternative.
> > > > 2. MinimalSelector should ignore empty alternatives
> > > >
> > > > Any objections ?
> > > >
> > > > I'm going apply the to the snapshot and experiment if it fixes the
> > > > issue
> > > >
> > > > cheers, Sergey
> > > >
> > > > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> > > > > Sergey,
> > > > >
> > > > > Not sure what would cause this. My suggestion would be to stick a
> > > > > breakpoint
> > > > > at the end of the PolicyIn and Out interceptor's handleMessage
> calls
> > >
> > > and
> > >
> > > > > have
> > > > > it print the interceptor chain. If the RM policy is enabled, it
> > >
> > > SHOULD
> > >
> > > > > have
> > > > > added the RM interceptors. That would at least tell you if it's
> a
> > > > > policy
> > > > > issue or an RM issue.
> > > > >
> > > > > Dan
> > > > >
> > > > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> > > > > > Hi
> > > > > >
> > > > > > I'm looking into the following issue.
> > > > > > WSDL fragment :
> > > > > >
> > > > > > <wsdl:binding name="SimpleServiceSoapBinding"
> > >
> > > type="tns:SimpleService">
> > >
> > > > > > <wsp:Policy>
> > > > > >
> > > > > > <wswa:UsingAddressing xmlns:wswa="
> > > > > >
> > > > > > http://www.w3.org/2006/05/addressing/wsdl"/>
> > > > > >
> > > > > > <wsrmp:RMAssertion xmlns:wsrmp="
> > > > > >
> > > > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> > > > > >
> > > > > > </wsp:Policy>
> > > > > >
> > > > > > </wsdl:binding>
> > > > > >
> > > > > > When the client invokes a simple echo() operation, the following
> is
> > > > > > happening on the wire :
> > > > > >
> > > > > > 1. WS-RM CreateSequence request is sent and a successful
> response
> > > > > > containing the sequence id/etc is sent back
> > > > > > 2. Actual echo() request is sent with WS-A and WSRM headers
> > >
> > > included
> > >
> > > > > > However the server replies with no WS-A/WS-RM headers and thus a
> > > > > > runtime policy verification fails on the client side.
> > > > > >
> > > > > > Note that no Spring is used in this case.
> > > > > >
> > > > > > Obviously, the client recognizes that the above policy needs to
> be
> > > > >
> > > > > applied
> > > > >
> > > > > > and the server initially responds well to a WS-RM only request.
> It
> > > > >
> > > > > appears
> > > > >
> > > > > > though it is happening due to WS-RM interceptors installed by
> > > > > > default on the server side.
> > > > > >
> > > > > > Question is : is it a bug that the server does not apply a policy
> > > > > > to the outbound message (it is probably not even enforcing it on
> > > > > > the inbound message too) in a WSDL-first with no Spring case ?
> > > > > > Also, why the client does recognize the policy requirement but
> the
> > > > > > server does not ?
> > > > > >
> > > > > > it's been awhile since I looked into the Ws-Policy code so some
> > >
> > > initial
> > >
> > > > > > feedback will help :-)
> > > > > >
> > > > > > thanks, Sergey
> > > > >
> > > > > --
> > > > > Daniel Kulp
> > > > > dkulp@apache.org
> > > > > http://dankulp.com/blog
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: WS-Policy is not applied to the outbound message on the server side (WSDL first)
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 26 July 2010 12:31:31 pm Sergey Beryozkin wrote:
> > If so, then either of those proposals would definitely change the
> > behavior of
> > things, especially on the client side. We kind of ran into this with
> > the TCK.
> >
> > For example, if the addressing policy is "optional", with the current
> > behavior, the client would not bother sending the addressing headers.
> > Doing
> > the addressing stuff slows things down so choosing the "empty"
> > alternative is
> > a good thing.
> >
> > I wondering if it's possible to allow the empty on outgoing on the
> > client, but
> > not on the server.
>
> that would probably be a right solution anyway given that as far as the
> server is concerned it has to prioritize on the non-empty alternative
> > Either that or we would need a new selector that somehow
> > would take the incoming policy into affect when calculating the outgoing
> > policy. For example, if the addressing/rm assertions were asserted on
> > incoming side, then chose an alternative that has those. Might be a bit
> > more
> > complicated to write. Plus, the PolicyEngine would have to updated to
> > allowing pulling the selector off the endpoint/message or similar.
> >
> > Another idea might be to have the PolicyEngine have two
> > AlternativeSelectors,
> > one for the requestor based requests that would be truely minimal and one
> > for
> > the other cases that would ignore the minimal.
> >
> > For this specific issue I like the idea of restricting the server side to
>
> choosing a non-empty alternative as it seems the simplest option and yet
> the correct one too.
Not really. IMO, the "correct" thing would be to somehow compare the possible
alternatives with the AssertionMap of the incoming request to figure out which
alternative is "most assertable" based on the assertions of the incoming
request. For example, there COULD be a policy that was use "either security
or RM". To select the correct policy on the outgoing side, you would really
need to look at the incoming assertions.
Unfortunately , that starts getting really complex and requires a bunch of API
changes. :-(
Dan
>
> cheers, Sergey
>
> > Dan
> >
> > On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
> > > Hi
> > >
> > >
> > > after spending quite a bit of time on debugging the issue I think I've
> > > traced where the problem is.
> > > Given that Policy with two assertions below we eventually get a
> >
> > normalized
> >
> > > policy, with a single ExactlyOnce and one alternative <All> with those
> >
> > two
> >
> > > simple assertions inside, this is stored with EndpointPolicyImpl.
> > >
> > > Next, we get an EffectivePolicyImpl but there we end up with two
> > > alternative, one is a proper All with WSA & RM, another one is empty.
> >
> > This
> >
> > > is not too bad but PolicyEngine in its supportsAlernative method
> > > returns "true" for an empty alternative such as <All/> and given that
> > > EffectivePolicyImpl uses a MinimalSelector by default, this empty
> > > alternative is actually overriding a previous valid one on the basis
> > > that it's size (0) is less than that of the valid one.
> > >
> > > I propose two fixes :
> > > 1. PolicyEngine.supportsAlernative has to return false for an empty
> > > alternative.
> > > 2. MinimalSelector should ignore empty alternatives
> > >
> > > Any objections ?
> > >
> > > I'm going apply the to the snapshot and experiment if it fixes the
> > > issue
> > >
> > > cheers, Sergey
> > >
> > > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org> wrote:
> > > > Sergey,
> > > >
> > > > Not sure what would cause this. My suggestion would be to stick a
> > > > breakpoint
> > > > at the end of the PolicyIn and Out interceptor's handleMessage calls
> >
> > and
> >
> > > > have
> > > > it print the interceptor chain. If the RM policy is enabled, it
> >
> > SHOULD
> >
> > > > have
> > > > added the RM interceptors. That would at least tell you if it's a
> > > > policy
> > > > issue or an RM issue.
> > > >
> > > > Dan
> > > >
> > > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> > > > > Hi
> > > > >
> > > > > I'm looking into the following issue.
> > > > > WSDL fragment :
> > > > >
> > > > > <wsdl:binding name="SimpleServiceSoapBinding"
> >
> > type="tns:SimpleService">
> >
> > > > > <wsp:Policy>
> > > > >
> > > > > <wswa:UsingAddressing xmlns:wswa="
> > > > >
> > > > > http://www.w3.org/2006/05/addressing/wsdl"/>
> > > > >
> > > > > <wsrmp:RMAssertion xmlns:wsrmp="
> > > > >
> > > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> > > > >
> > > > > </wsp:Policy>
> > > > >
> > > > > </wsdl:binding>
> > > > >
> > > > > When the client invokes a simple echo() operation, the following is
> > > > > happening on the wire :
> > > > >
> > > > > 1. WS-RM CreateSequence request is sent and a successful response
> > > > > containing the sequence id/etc is sent back
> > > > > 2. Actual echo() request is sent with WS-A and WSRM headers
> >
> > included
> >
> > > > > However the server replies with no WS-A/WS-RM headers and thus a
> > > > > runtime policy verification fails on the client side.
> > > > >
> > > > > Note that no Spring is used in this case.
> > > > >
> > > > > Obviously, the client recognizes that the above policy needs to be
> > > >
> > > > applied
> > > >
> > > > > and the server initially responds well to a WS-RM only request. It
> > > >
> > > > appears
> > > >
> > > > > though it is happening due to WS-RM interceptors installed by
> > > > > default on the server side.
> > > > >
> > > > > Question is : is it a bug that the server does not apply a policy
> > > > > to the outbound message (it is probably not even enforcing it on
> > > > > the inbound message too) in a WSDL-first with no Spring case ?
> > > > > Also, why the client does recognize the policy requirement but the
> > > > > server does not ?
> > > > >
> > > > > it's been awhile since I looked into the Ws-Policy code so some
> >
> > initial
> >
> > > > > feedback will help :-)
> > > > >
> > > > > thanks, Sergey
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org
> > > > http://dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Policy is not applied to the outbound message on the server
side (WSDL first)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Dan
On Fri, Jul 23, 2010 at 8:13 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Sergey,
>
> Any idea where the second (empty) alternative is coming from? Is it due
> to
> optional=true policies?
>
>
I've forgotten that optional assertions get normalized into a policy with
two alternatives, one of them being empty.
Will resumed investigating the issue tomorrow
> If so, then either of those proposals would definitely change the behavior
> of
> things, especially on the client side. We kind of ran into this with the
> TCK.
>
> For example, if the addressing policy is "optional", with the current
> behavior, the client would not bother sending the addressing headers.
> Doing
> the addressing stuff slows things down so choosing the "empty" alternative
> is
> a good thing.
>
> I wondering if it's possible to allow the empty on outgoing on the client,
> but
> not on the server.
that would probably be a right solution anyway given that as far as the
server is concerned it has to prioritize on the non-empty alternative
> Either that or we would need a new selector that somehow
> would take the incoming policy into affect when calculating the outgoing
> policy. For example, if the addressing/rm assertions were asserted on
> incoming side, then chose an alternative that has those. Might be a bit
> more
> complicated to write. Plus, the PolicyEngine would have to updated to
> allowing pulling the selector off the endpoint/message or similar.
>
> Another idea might be to have the PolicyEngine have two
> AlternativeSelectors,
> one for the requestor based requests that would be truely minimal and one
> for
> the other cases that would ignore the minimal.
>
> For this specific issue I like the idea of restricting the server side to
choosing a non-empty alternative as it seems the simplest option and yet the
correct one too.
cheers, Sergey
> Dan
>
>
>
> On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
> > Hi
> >
> >
> > after spending quite a bit of time on debugging the issue I think I've
> > traced where the problem is.
> > Given that Policy with two assertions below we eventually get a
> normalized
> > policy, with a single ExactlyOnce and one alternative <All> with those
> two
> > simple assertions inside, this is stored with EndpointPolicyImpl.
> >
> > Next, we get an EffectivePolicyImpl but there we end up with two
> > alternative, one is a proper All with WSA & RM, another one is empty.
> This
> > is not too bad but PolicyEngine in its supportsAlernative method returns
> > "true" for an empty alternative such as <All/> and given that
> > EffectivePolicyImpl uses a MinimalSelector by default, this empty
> > alternative is actually overriding a previous valid one on the basis that
> > it's size (0) is less than that of the valid one.
> >
> > I propose two fixes :
> > 1. PolicyEngine.supportsAlernative has to return false for an empty
> > alternative.
> > 2. MinimalSelector should ignore empty alternatives
> >
> > Any objections ?
> >
> > I'm going apply the to the snapshot and experiment if it fixes the issue
> >
> > cheers, Sergey
> >
> > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org> wrote:
> > > Sergey,
> > >
> > > Not sure what would cause this. My suggestion would be to stick a
> > > breakpoint
> > > at the end of the PolicyIn and Out interceptor's handleMessage calls
> and
> > > have
> > > it print the interceptor chain. If the RM policy is enabled, it
> SHOULD
> > > have
> > > added the RM interceptors. That would at least tell you if it's a
> > > policy
> > > issue or an RM issue.
> > >
> > > Dan
> > >
> > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> > > > Hi
> > > >
> > > > I'm looking into the following issue.
> > > > WSDL fragment :
> > > >
> > > > <wsdl:binding name="SimpleServiceSoapBinding"
> type="tns:SimpleService">
> > > >
> > > > <wsp:Policy>
> > > >
> > > > <wswa:UsingAddressing xmlns:wswa="
> > > >
> > > > http://www.w3.org/2006/05/addressing/wsdl"/>
> > > >
> > > > <wsrmp:RMAssertion xmlns:wsrmp="
> > > >
> > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> > > >
> > > > </wsp:Policy>
> > > >
> > > > </wsdl:binding>
> > > >
> > > > When the client invokes a simple echo() operation, the following is
> > > > happening on the wire :
> > > >
> > > > 1. WS-RM CreateSequence request is sent and a successful response
> > > > containing the sequence id/etc is sent back
> > > > 2. Actual echo() request is sent with WS-A and WSRM headers
> included
> > > >
> > > > However the server replies with no WS-A/WS-RM headers and thus a
> > > > runtime policy verification fails on the client side.
> > > >
> > > > Note that no Spring is used in this case.
> > > >
> > > > Obviously, the client recognizes that the above policy needs to be
> > >
> > > applied
> > >
> > > > and the server initially responds well to a WS-RM only request. It
> > >
> > > appears
> > >
> > > > though it is happening due to WS-RM interceptors installed by default
> > > > on the server side.
> > > >
> > > > Question is : is it a bug that the server does not apply a policy to
> > > > the outbound message (it is probably not even enforcing it on the
> > > > inbound message too) in a WSDL-first with no Spring case ? Also, why
> > > > the client does recognize the policy requirement but the server does
> > > > not ?
> > > >
> > > > it's been awhile since I looked into the Ws-Policy code so some
> initial
> > > > feedback will help :-)
> > > >
> > > > thanks, Sergey
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: WS-Policy is not applied to the outbound message on the server
side (WSDL first)
Posted by Nilupa Bandara <ni...@gmail.com>.
On Mon, Jul 26, 2010 at 11:31 PM, Nilupa Bandara <nilupa.manamperi@gmail.com
> wrote:
>
>
> On Fri, Jul 23, 2010 at 9:13 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> Sergey,
>>
>> Any idea where the second (empty) alternative is coming from? Is it due
>> to
>> optional=true policies?
>>
>
> To which policies do you refer by 'optional=true' policies ? (None of the
> assertions are marked as optional in the policy expression defined in the
> WSDL in question)
>
And I guess they refer to some internal policies of CXF framework and where
can I locate them ?
>
>> If so, then either of those proposals would definitely change the behavior
>> of
>> things, especially on the client side. We kind of ran into this with the
>> TCK.
>>
>> For example, if the addressing policy is "optional", with the current
>> behavior, the client would not bother sending the addressing headers.
>> Doing
>> the addressing stuff slows things down so choosing the "empty" alternative
>> is
>> a good thing.
>>
>> I wondering if it's possible to allow the empty on outgoing on the client,
>> but
>> not on the server. Either that or we would need a new selector that
>> somehow
>> would take the incoming policy into affect when calculating the outgoing
>> policy. For example, if the addressing/rm assertions were asserted on
>> incoming side, then chose an alternative that has those. Might be a bit
>> more
>> complicated to write. Plus, the PolicyEngine would have to updated to
>> allowing pulling the selector off the endpoint/message or similar.
>>
>> Another idea might be to have the PolicyEngine have two
>> AlternativeSelectors,
>> one for the requestor based requests that would be truely minimal and one
>> for
>> the other cases that would ignore the minimal.
>>
>> Dan
>>
>>
>>
>> On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
>> > Hi
>> >
>> >
>> > after spending quite a bit of time on debugging the issue I think I've
>> > traced where the problem is.
>> > Given that Policy with two assertions below we eventually get a
>> normalized
>> > policy, with a single ExactlyOnce and one alternative <All> with those
>> two
>> > simple assertions inside, this is stored with EndpointPolicyImpl.
>> >
>> > Next, we get an EffectivePolicyImpl but there we end up with two
>> > alternative, one is a proper All with WSA & RM, another one is empty.
>> This
>> > is not too bad but PolicyEngine in its supportsAlernative method returns
>> > "true" for an empty alternative such as <All/> and given that
>> > EffectivePolicyImpl uses a MinimalSelector by default, this empty
>> > alternative is actually overriding a previous valid one on the basis
>> that
>> > it's size (0) is less than that of the valid one.
>> >
>> > I propose two fixes :
>> > 1. PolicyEngine.supportsAlernative has to return false for an empty
>> > alternative.
>> > 2. MinimalSelector should ignore empty alternatives
>> >
>> > Any objections ?
>> >
>> > I'm going apply the to the snapshot and experiment if it fixes the issue
>> >
>> > cheers, Sergey
>> >
>> > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>> > > Sergey,
>> > >
>> > > Not sure what would cause this. My suggestion would be to stick a
>> > > breakpoint
>> > > at the end of the PolicyIn and Out interceptor's handleMessage calls
>> and
>> > > have
>> > > it print the interceptor chain. If the RM policy is enabled, it
>> SHOULD
>> > > have
>> > > added the RM interceptors. That would at least tell you if it's a
>> > > policy
>> > > issue or an RM issue.
>> > >
>> > > Dan
>> > >
>> > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
>> > > > Hi
>> > > >
>> > > > I'm looking into the following issue.
>> > > > WSDL fragment :
>> > > >
>> > > > <wsdl:binding name="SimpleServiceSoapBinding"
>> type="tns:SimpleService">
>> > > >
>> > > > <wsp:Policy>
>> > > >
>> > > > <wswa:UsingAddressing xmlns:wswa="
>> > > >
>> > > > http://www.w3.org/2006/05/addressing/wsdl"/>
>> > > >
>> > > > <wsrmp:RMAssertion xmlns:wsrmp="
>> > > >
>> > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
>> > > >
>> > > > </wsp:Policy>
>> > > >
>> > > > </wsdl:binding>
>> > > >
>> > > > When the client invokes a simple echo() operation, the following is
>> > > > happening on the wire :
>> > > >
>> > > > 1. WS-RM CreateSequence request is sent and a successful response
>> > > > containing the sequence id/etc is sent back
>> > > > 2. Actual echo() request is sent with WS-A and WSRM headers
>> included
>> > > >
>> > > > However the server replies with no WS-A/WS-RM headers and thus a
>> > > > runtime policy verification fails on the client side.
>> > > >
>> > > > Note that no Spring is used in this case.
>> > > >
>> > > > Obviously, the client recognizes that the above policy needs to be
>> > >
>> > > applied
>> > >
>> > > > and the server initially responds well to a WS-RM only request. It
>> > >
>> > > appears
>> > >
>> > > > though it is happening due to WS-RM interceptors installed by
>> default
>> > > > on the server side.
>> > > >
>> > > > Question is : is it a bug that the server does not apply a policy to
>> > > > the outbound message (it is probably not even enforcing it on the
>> > > > inbound message too) in a WSDL-first with no Spring case ? Also, why
>> > > > the client does recognize the policy requirement but the server does
>> > > > not ?
>> > > >
>> > > > it's been awhile since I looked into the Ws-Policy code so some
>> initial
>> > > > feedback will help :-)
>> > > >
>> > > > thanks, Sergey
>> > >
>> > > --
>> > > Daniel Kulp
>> > > dkulp@apache.org
>> > > http://dankulp.com/blog
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
>
> --
> Nilupa Bandara
>
>
--
Nilupa Bandara
Re: WS-Policy is not applied to the outbound message on the server
side (WSDL first)
Posted by Nilupa Bandara <ni...@gmail.com>.
On Fri, Jul 23, 2010 at 9:13 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Sergey,
>
> Any idea where the second (empty) alternative is coming from? Is it due
> to
> optional=true policies?
>
To which policies do you refer by 'optional=true' policies ? (None of the
assertions are marked as optional in the policy expression defined in the
WSDL in question)
Sanka
>
> If so, then either of those proposals would definitely change the behavior
> of
> things, especially on the client side. We kind of ran into this with the
> TCK.
>
> For example, if the addressing policy is "optional", with the current
> behavior, the client would not bother sending the addressing headers.
> Doing
> the addressing stuff slows things down so choosing the "empty" alternative
> is
> a good thing.
>
> I wondering if it's possible to allow the empty on outgoing on the client,
> but
> not on the server. Either that or we would need a new selector that
> somehow
> would take the incoming policy into affect when calculating the outgoing
> policy. For example, if the addressing/rm assertions were asserted on
> incoming side, then chose an alternative that has those. Might be a bit
> more
> complicated to write. Plus, the PolicyEngine would have to updated to
> allowing pulling the selector off the endpoint/message or similar.
>
> Another idea might be to have the PolicyEngine have two
> AlternativeSelectors,
> one for the requestor based requests that would be truely minimal and one
> for
> the other cases that would ignore the minimal.
>
> Dan
>
>
>
> On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
> > Hi
> >
> >
> > after spending quite a bit of time on debugging the issue I think I've
> > traced where the problem is.
> > Given that Policy with two assertions below we eventually get a
> normalized
> > policy, with a single ExactlyOnce and one alternative <All> with those
> two
> > simple assertions inside, this is stored with EndpointPolicyImpl.
> >
> > Next, we get an EffectivePolicyImpl but there we end up with two
> > alternative, one is a proper All with WSA & RM, another one is empty.
> This
> > is not too bad but PolicyEngine in its supportsAlernative method returns
> > "true" for an empty alternative such as <All/> and given that
> > EffectivePolicyImpl uses a MinimalSelector by default, this empty
> > alternative is actually overriding a previous valid one on the basis that
> > it's size (0) is less than that of the valid one.
> >
> > I propose two fixes :
> > 1. PolicyEngine.supportsAlernative has to return false for an empty
> > alternative.
> > 2. MinimalSelector should ignore empty alternatives
> >
> > Any objections ?
> >
> > I'm going apply the to the snapshot and experiment if it fixes the issue
> >
> > cheers, Sergey
> >
> > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org> wrote:
> > > Sergey,
> > >
> > > Not sure what would cause this. My suggestion would be to stick a
> > > breakpoint
> > > at the end of the PolicyIn and Out interceptor's handleMessage calls
> and
> > > have
> > > it print the interceptor chain. If the RM policy is enabled, it
> SHOULD
> > > have
> > > added the RM interceptors. That would at least tell you if it's a
> > > policy
> > > issue or an RM issue.
> > >
> > > Dan
> > >
> > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> > > > Hi
> > > >
> > > > I'm looking into the following issue.
> > > > WSDL fragment :
> > > >
> > > > <wsdl:binding name="SimpleServiceSoapBinding"
> type="tns:SimpleService">
> > > >
> > > > <wsp:Policy>
> > > >
> > > > <wswa:UsingAddressing xmlns:wswa="
> > > >
> > > > http://www.w3.org/2006/05/addressing/wsdl"/>
> > > >
> > > > <wsrmp:RMAssertion xmlns:wsrmp="
> > > >
> > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> > > >
> > > > </wsp:Policy>
> > > >
> > > > </wsdl:binding>
> > > >
> > > > When the client invokes a simple echo() operation, the following is
> > > > happening on the wire :
> > > >
> > > > 1. WS-RM CreateSequence request is sent and a successful response
> > > > containing the sequence id/etc is sent back
> > > > 2. Actual echo() request is sent with WS-A and WSRM headers
> included
> > > >
> > > > However the server replies with no WS-A/WS-RM headers and thus a
> > > > runtime policy verification fails on the client side.
> > > >
> > > > Note that no Spring is used in this case.
> > > >
> > > > Obviously, the client recognizes that the above policy needs to be
> > >
> > > applied
> > >
> > > > and the server initially responds well to a WS-RM only request. It
> > >
> > > appears
> > >
> > > > though it is happening due to WS-RM interceptors installed by default
> > > > on the server side.
> > > >
> > > > Question is : is it a bug that the server does not apply a policy to
> > > > the outbound message (it is probably not even enforcing it on the
> > > > inbound message too) in a WSDL-first with no Spring case ? Also, why
> > > > the client does recognize the policy requirement but the server does
> > > > not ?
> > > >
> > > > it's been awhile since I looked into the Ws-Policy code so some
> initial
> > > > feedback will help :-)
> > > >
> > > > thanks, Sergey
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
--
Nilupa Bandara
Re: WS-Policy is not applied to the outbound message on the server side (WSDL first)
Posted by Daniel Kulp <dk...@apache.org>.
Sergey,
Any idea where the second (empty) alternative is coming from? Is it due to
optional=true policies?
If so, then either of those proposals would definitely change the behavior of
things, especially on the client side. We kind of ran into this with the
TCK.
For example, if the addressing policy is "optional", with the current
behavior, the client would not bother sending the addressing headers. Doing
the addressing stuff slows things down so choosing the "empty" alternative is
a good thing.
I wondering if it's possible to allow the empty on outgoing on the client, but
not on the server. Either that or we would need a new selector that somehow
would take the incoming policy into affect when calculating the outgoing
policy. For example, if the addressing/rm assertions were asserted on
incoming side, then chose an alternative that has those. Might be a bit more
complicated to write. Plus, the PolicyEngine would have to updated to
allowing pulling the selector off the endpoint/message or similar.
Another idea might be to have the PolicyEngine have two AlternativeSelectors,
one for the requestor based requests that would be truely minimal and one for
the other cases that would ignore the minimal.
Dan
On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote:
> Hi
>
>
> after spending quite a bit of time on debugging the issue I think I've
> traced where the problem is.
> Given that Policy with two assertions below we eventually get a normalized
> policy, with a single ExactlyOnce and one alternative <All> with those two
> simple assertions inside, this is stored with EndpointPolicyImpl.
>
> Next, we get an EffectivePolicyImpl but there we end up with two
> alternative, one is a proper All with WSA & RM, another one is empty. This
> is not too bad but PolicyEngine in its supportsAlernative method returns
> "true" for an empty alternative such as <All/> and given that
> EffectivePolicyImpl uses a MinimalSelector by default, this empty
> alternative is actually overriding a previous valid one on the basis that
> it's size (0) is less than that of the valid one.
>
> I propose two fixes :
> 1. PolicyEngine.supportsAlernative has to return false for an empty
> alternative.
> 2. MinimalSelector should ignore empty alternatives
>
> Any objections ?
>
> I'm going apply the to the snapshot and experiment if it fixes the issue
>
> cheers, Sergey
>
> On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org> wrote:
> > Sergey,
> >
> > Not sure what would cause this. My suggestion would be to stick a
> > breakpoint
> > at the end of the PolicyIn and Out interceptor's handleMessage calls and
> > have
> > it print the interceptor chain. If the RM policy is enabled, it SHOULD
> > have
> > added the RM interceptors. That would at least tell you if it's a
> > policy
> > issue or an RM issue.
> >
> > Dan
> >
> > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> > > Hi
> > >
> > > I'm looking into the following issue.
> > > WSDL fragment :
> > >
> > > <wsdl:binding name="SimpleServiceSoapBinding" type="tns:SimpleService">
> > >
> > > <wsp:Policy>
> > >
> > > <wswa:UsingAddressing xmlns:wswa="
> > >
> > > http://www.w3.org/2006/05/addressing/wsdl"/>
> > >
> > > <wsrmp:RMAssertion xmlns:wsrmp="
> > >
> > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> > >
> > > </wsp:Policy>
> > >
> > > </wsdl:binding>
> > >
> > > When the client invokes a simple echo() operation, the following is
> > > happening on the wire :
> > >
> > > 1. WS-RM CreateSequence request is sent and a successful response
> > > containing the sequence id/etc is sent back
> > > 2. Actual echo() request is sent with WS-A and WSRM headers included
> > >
> > > However the server replies with no WS-A/WS-RM headers and thus a
> > > runtime policy verification fails on the client side.
> > >
> > > Note that no Spring is used in this case.
> > >
> > > Obviously, the client recognizes that the above policy needs to be
> >
> > applied
> >
> > > and the server initially responds well to a WS-RM only request. It
> >
> > appears
> >
> > > though it is happening due to WS-RM interceptors installed by default
> > > on the server side.
> > >
> > > Question is : is it a bug that the server does not apply a policy to
> > > the outbound message (it is probably not even enforcing it on the
> > > inbound message too) in a WSDL-first with no Spring case ? Also, why
> > > the client does recognize the policy requirement but the server does
> > > not ?
> > >
> > > it's been awhile since I looked into the Ws-Policy code so some initial
> > > feedback will help :-)
> > >
> > > thanks, Sergey
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Policy is not applied to the outbound message on the server
side (WSDL first)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
after spending quite a bit of time on debugging the issue I think I've
traced where the problem is.
Given that Policy with two assertions below we eventually get a normalized
policy, with a single ExactlyOnce and one alternative <All> with those two
simple assertions inside, this is stored with EndpointPolicyImpl.
Next, we get an EffectivePolicyImpl but there we end up with two
alternative, one is a proper All with WSA & RM, another one is empty. This
is not too bad but PolicyEngine in its supportsAlernative method returns
"true" for an empty alternative such as <All/> and given that
EffectivePolicyImpl uses a MinimalSelector by default, this empty
alternative is actually overriding a previous valid one on the basis that
it's size (0) is less than that of the valid one.
I propose two fixes :
1. PolicyEngine.supportsAlernative has to return false for an empty
alternative.
2. MinimalSelector should ignore empty alternatives
Any objections ?
I'm going apply the to the snapshot and experiment if it fixes the issue
cheers, Sergey
On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Sergey,
>
> Not sure what would cause this. My suggestion would be to stick a
> breakpoint
> at the end of the PolicyIn and Out interceptor's handleMessage calls and
> have
> it print the interceptor chain. If the RM policy is enabled, it SHOULD
> have
> added the RM interceptors. That would at least tell you if it's a
> policy
> issue or an RM issue.
>
> Dan
>
>
> On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote:
> > Hi
> >
> > I'm looking into the following issue.
> > WSDL fragment :
> >
> > <wsdl:binding name="SimpleServiceSoapBinding" type="tns:SimpleService">
> > <wsp:Policy>
> > <wswa:UsingAddressing xmlns:wswa="
> > http://www.w3.org/2006/05/addressing/wsdl"/>
> > <wsrmp:RMAssertion xmlns:wsrmp="
> > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/>
> > </wsp:Policy>
> > </wsdl:binding>
> >
> > When the client invokes a simple echo() operation, the following is
> > happening on the wire :
> >
> > 1. WS-RM CreateSequence request is sent and a successful response
> > containing the sequence id/etc is sent back
> > 2. Actual echo() request is sent with WS-A and WSRM headers included
> >
> > However the server replies with no WS-A/WS-RM headers and thus a runtime
> > policy verification fails on the client side.
> >
> > Note that no Spring is used in this case.
> >
> > Obviously, the client recognizes that the above policy needs to be
> applied
> > and the server initially responds well to a WS-RM only request. It
> appears
> > though it is happening due to WS-RM interceptors installed by default on
> > the server side.
> >
> > Question is : is it a bug that the server does not apply a policy to the
> > outbound message (it is probably not even enforcing it on the inbound
> > message too) in a WSDL-first with no Spring case ? Also, why the client
> > does recognize the policy requirement but the server does not ?
> >
> > it's been awhile since I looked into the Ws-Policy code so some initial
> > feedback will help :-)
> >
> > thanks, Sergey
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>