cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: More on server response policies
Date Thu, 09 Oct 2008 14:38:57 GMT
Hi

> Suppose you have this config:
>
> <jaxws:endpoint ...>
> <jaxws:features>
> <cxf:PolicyFeature>
>   <wsp:Policy><foo:Bar/></wsp:Policy>
> </cxf:PolicyFeature>
> </jaxws:features>
> </jaxws:endpoint>
>
> 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. As far as the policy verification is concerned, the default behaviour
is to fail on the inbound path if a single 
alternative includinfg a single <foo:Bar/> policy expression has not been asserted and
(to be fixed) log a message on the outbound 
path.

>> All required interceptors are
>> installed - but the api allows for on-demand interceptors  installation (for
>> ex, based in the in message's content & headers).
>
> Correct.  Or more appropriately, based on the actual content of the  policy.

Not necessarily. Consider an optional MTOM policy assertion. There's no strict need to install
an MTOM interceptor
in advance, untill a given message arrives. You can 2 messages coming in, one is non-MTOM,
another one is.

>
>> AFAIK,
>> PolicyVerificationInInterceptor would say OK as long as at least one  of the
>> alternatives is fully satisfied. In your example we have a compact  policy
>> expression, so there'no problems if either <foo:Bar/> or <gnu:Gnat/>
 has
>> been asserted.
>>
>> On the outbound path only the alternative which has been selected  during the
>> inbound path should be optionally verified. I don't think any  alternative
>> selection algorithm should apply on the outbound path as we already  have an
>> alternative active in the scope of a given operation.
>
> That assumes the effective policy is the same on the inbound and  outbound sides.  I
think that's an invalid assumption (as I 
> think you  are saying, as well).  Or at least I think we should be able to  discriminate
between inbound and outbound policies.  I 
> stand corrected  in the case of WSDL, but I think we need a way to make the same  distinction
in spring (and however else we 
> retrieve policy).

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 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>

IMHO this is more compact and easier on the eye. 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>

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. 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.

>
> I think this gets us over a hump, but I also think it's kind of a cop- out.  Why log
anything?  Why even do the check?  What's the 
> purpose,  if there's no tangible side-effect?  Choke up a log with more garbage?

So we can have a default scope be "in-only", but when we want to block the response we can
override it.

>
>>
>>
>> While (on the server side) PolicyVerificationInInterceptor is useful  in that
>> it ensures that at least one alternative has been met, its out  counterpart
>> is of little use. Unless we provide some hints.
>
> 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.

>

>
> Not sure what you mean here.  Attributes on the wsp:Policy elements,  themselves?  I'd
think there'd be a better way to do that, 
> than to add  proprietary stuff to standard policy expressions.  At any rate, if  that's
what you mean, then I think we should try 
> to avoid it, since it  won't be in any way interoperable.

any client runtime should be able to ignore unrecognized attributes. Any policy expression
should have an extension point for any additional attributes. I honestly think it's an issue
at all.
If we ever have to deal with 3rd party policies with closed schemas then we can also use your
proposed
extension.
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.


Cheers, Sergey


>
>>
>>
>> Without such helper attributes the default (server) behavior should  likely
>> be :
>> - PolicyVerificationInInterceptor throws fault if none of the  alternatives
>> has been met (as it is now)
>> - PolicyVerificationOutInterceptor logs a FINE message if not all of  the
>> expressions in the alternative selected during the inbound  invocation has
>> been met.
>
> Why?  What possible use is this to the user?

See above please.

>
> I'll reiterate that the API on setting a PolicyAlternativeSelector is  too coarse --
it's on the PolicyEngine, which is basically 
> in 1-1  correspondence with the Bus.  I can think of 4 different ways you'd  want to
configure one of these guys (client/server 
> in/out), and you'd  want to be able to configure that on a per-endpoint basis (at least).

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.

Cheers, Sergey

>
> -Fred 

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

Mime
View raw message