cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: More on server response policies
Date Thu, 09 Oct 2008 16:02:32 GMT
Hi Fred

I strat thinking this message gets a bit off-track :-) Few more comments.

> That's fine, in that the AssertionBuilder can render a decision about  what interceptors
to add to the chain.  But that won't 
> solve the bug  I've identified.

As we've said many times what will solve this problem is the out verifier logging a message.
For now, untill
we sort out the issue of hints.

>> I actually think that the single effective policy should apply to  the given operation,
in/out. But this policy can contain 
>> expressions  which are valid for the outbound only or inbound only or both. I  don't
think WS-Policy provides for effective 
>> polices for in or out  only, It's a single effective policy instance for the scope
of a  given operation. Though the 
>> AssertionInfoMap should be in/out- specific.
> How are you going to render that calculation?  The policy framework  has and should have
no idea what the content of the 
> assertions is.   You don't really want to go peeking into the assertion for  breadcrumbs,
do you?

Sorry, not following you. Neither I'm talking of the policy engine peeking into the individual
PolicyAssertion is an interface and the AssertionInfoMap could check the scopes (when they're

>>> How about this, for a proposal:
>>> <jaxws:endpoint ...>
>>> <jaxws:features>
>>> <cxf:PolicyFeature>
>>>  <wsp:Policy><foo:Bar/></wsp:Policy>
>>> </cxf:PolicyFeature>
>>> <cxf:InboundPolicyFeature>             <!-- new type -->
>>>  <wsp:Policy><gnu:Gnat/></wsp:Policy>
>>> </cxf:InboundPolicyFeature>
>>> <cxf:OutboundPolicyFeature>             <!-- new type -->
>>>  <wsp:Policy><bling:Blang/></wsp:Policy>
>>> </cxf:OutboundPolicyFeature>
>>> </jaxws:features>
>>> </jaxws:endpoint>
>> I'd just prefer
>> <wsp:Policy><bling:Blang cxf:scope="default/in/out"/></wsp:Policy>
> So, what you're saying is that the policy framework would know  something special about
the cxf:scope attribute, and that any 
> schema  for policy assertions would need to be adjusted to support such an  attribute.
 That's kind of messy, isn't it?

Not at all. I think we're getting off track again here. First you're saying that there're
no need
for the out interceptor at all, and now you're saying that something has to be adjusted. As
I said,
any more or less decent schema has the default extension point for 'any' attributes. Next,
often there's
no even need to verify on the outbound path. Only for those polices which really need to do
it we can add
such an attribute.

> I agree that your proposal is semantically equivalent to mine.  I just  think it's better
to treat the customer's (i.e., the 
> customer of the  policy f/w) policies as kind of sacrosanct.
>> IMHO this is more compact and easier on the eye.
> Well, that's an aesthetic argument, which is hard to argue against,  because of its subjectivity.
 Let's talk about it from a 
> technical,  rather than aesthetic point of view.

No. It's not an aesthetic argument. This solution is more portable in that it can be applied
policies both in the spring configuration and in WSDL. It's more compact and given that you're
concerned about the overall 
complexity of Ws-Policy expression I don't get the point of this comment : isn't it what we're
after = reducing the complexity as 
much as possible ?

Finally, I just don't think it works at all :

>>> <cxf:PolicyFeature>
>>>  <wsp:Policy><foo:Bar/></wsp:Policy>
>>> </cxf:PolicyFeature>
>>> <cxf:InboundPolicyFeature>             <!-- new type -->
>>>  <wsp:Policy><gnu:Gnat/></wsp:Policy>
>>> </cxf:InboundPolicyFeature>

A single Policy (alternative) expression may contain a bunch of expressions. So instead of
<wsp:Policy><foo:Bar/><bar:Baz wsp:scope="out-only"/></wsp:Policy>

you suggest creating a single feature per single expression. I disagree.

> Right, but isn't the wsdl:port really equivalent to the jax:ws  endpoint?  I thought
Dan's point was that you could associate 
> policies  with in/out messages in the binding, and that would be your mechanism  for
specifying different effective policies for 
> the in and out  channels.  And that works beautifully in WSDL.  My needs are outside
 of WSDL, so I'd like a spring-based 
> mechanism for doing the same kind  of thing.

No, that's not correct. As I've said many times before, the fact that your policies live in
spring does not mean that they're different from those living in WSDL. Those which live in
will be attached to WSDL once I fix the pending bug (with truly private stuff being removed).
 In both cases
these polices are of common interest to both client and server. This is the point of using
of WS-Policy.
I don't want to conflate this thread with the discussions on teh purpose of WS-policy though.

>> We can also suggest to the ws-policy group to consider standardizing  on such attribute
(as it can be of real help to client 
>> runtimes) in  the next maintenance release of the spec, whenever it happens.
> Yeah, well, that's not gonna help me with my Q4 release.

I'm sorry - don't get this comment either.

>> On the client it's none needed either - the client needs to iterate  through all
the available alternatives and find the best 
>> one.
> Interesting.  So it should be the policy consumer that selects the  alternatives?  I
don't think the current architecture supports 
> that,  does it?

PolicyAlternativeSelector is broken, It has to go. It does not make sense to select only the
first alternative,
or the last or the middle one because it's never going to go reliably.

Cheers, Sergey

> -Fred 

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

View raw message