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 assertions,
PolicyAssertion is an interface and the AssertionInfoMap could check the scopes
(when they're introduced)
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 to
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 Spring
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
