On Oct 9, 2008, at 10:38 AM, Sergey Beryozkin wrote:
Does <foo:Bar> apply to the inbound our outbound path? Or both?
What are the semantics here?
This coarse-graned policy applies to an endpoint so as I said it's
up to the <foo:Bar/> implementation as to whether it will affect in/
out/both pathes.
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.
Correct. Or more appropriately, based on the actual content of
the policy.
Not necessarily. ...
I guess I wasn't claiming policy content was the only deciding
factor. Let's just drop it.
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?
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? Would it also mean that
policy assertions were less portable, at least as far as copying/
pasting policies across documents is concerned? It's bad enough, with
all of the namespaces you need to keep track of in a typical CXF
config file.
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.
Furthermore, when such policies will be dynamicallyt attached to
WSDL instance, it would provide more hints to client runtimes/tools.
Such attribute can also be applied when polices are explicitly
attached to WSDL. For ex, as I said earlier, there's no explicit
indication to verifiers on the scope of this policy when it's
attached to some container element like wsdl:port
<wsdl:service>
<wsdl:port>
<wsp:Policy><bling:Blang/></wsp:Policy>
</wsdl:port>
</wsdl:service>
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.
we have a PolicyAssertion abstraction and we can add a helper method
like getScope(), by default it applies to say 'in' only or in/out
with possisble overrides.
To be honest though, I wouldn't be too concerned now about ensuring
that outbond policy verifier fails (or reports a warning). I reckon
the default behaviour (of just logging some FINE message) would do
in case say <bling:Blang/> ends up in the list of policies.
Well, I think i) it's a waste of time to do -- why do something if it
has no purpose -- green computing, and all that. But also, ii) it's
just going to raise a question with a customer. "Why is there is log
entry that says something failed? The request passed! What's going
on? Quick, file a bug."
Only when it's absolutely critical that an outbound message does not
leave the server runtime if some policies have not been applied to
the outbound message (SLA agreement with non policy aware client
runtimes for ex) then I'd consider adding such hints.
Hold it -- so you're saying this interceptor should raise a fault?
Yup. If it's of no use, remove it.
Mostly agreed but see above - we might need it at some time. And
it's probably can behave differently on the client side.
It's surely needed on the client side -- I wasn't saying to remove
verification on the outbound side of any side of a request. My
suggestion was to remove the interceptor from the outbound server
response interceptor chain, as it's really doing nothing but chewing
up clock cycles.
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.
And I'd like to stress again that PolicyAlternativeSelector is
really not needed at all and it needs to be deprecated.
On the server side any of the many available alternatives can be
valid at any moment of time for a given message and once the
effective policy is calculated it should stay fixed for the outbound
path. Thus no need for any special alternative algorithms on the
server.
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?
-Fred
