cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Ideas for a WS-Policy Framework for CXF
Date Mon, 15 Jan 2007 14:14:13 GMT
 

> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com] 
> Sent: 15 January 2007 09:21
> To: cxf-dev@incubator.apache.org
> Subject: Ideas for a WS-Policy Framework for CXF
> 
> I have written up some ideas on a WS-Policy implementation 
> for CXF on the wiki: 
> http://cwiki.apache.org/confluence/display/CXF/WS-Policy+Framework
> Any feedback appreciated.

Hi Andrea,

A couple of thoughts on this ... 

On the issue of the server-side assertion verification, can we
distinguish two different classes of assertion:

1. Assertions that are manifest from the gross incoming transport-level
packets, without requiring any introspection of the actual message
payload, and may even be enforceable prior to the payload being
available to the receiver ... e.g. asserting that the socket-level comms
are encrypted with a key strength of at least 128 bits, which could be
enforced via a TLS handshake, in advance of any message data being sent.

2. Assertions that are only manifest after introspection of the message
payload ... e.g. asserting that addressing is used, in the sense that
WS-A headers are present in the incoming message.

Can we impose the restriction that ONLY assertions in class #2 may be
set per-operation or per-message on the receiver-side?  

Whereas an assertion of class #1 would only be settable for the entire
endpoint (as this is the level of granularity of the transport
listener). In WSDL (1.1) terms, such a policy expression could be
attached to a portType, but not an operation or message. 

So for example, a security policy that would require a specific type of
listener to be launched would be limited to endpoint-level granularity
... e.g. a HTTPS listener with enabled cipher suites satisfying at least
128 bit encryption could NOT be required by a server-side per-operation
or per-message policy assertion.
 
--

On the client-side, for performance reasons I think it would be good to
avoid traversing the AssertionBuilders for every invocation. Instead, we
could optimize the process to re-use the policy reconciliation done for
previous invocations.

Off the top of my head, something like the following could work:

1. Maintain flyweighted policy sets, so that these may be compared
efficiently for equality using the == operator (as opposed to doing a
deep compare).

2. Cache the interceptor chain resulting from the traversal of the
AssertBuilders for a particular merged policy set.

3. Maintain a second-level cache (only checked if the cache-lookup from
step #2 yields nothing) of interceptor chains, which is keyed on
isCompatible()-style logic as opposed to equality. Dumb example, but
suppose we consider the RM BaseRetransmissionInterval to be a upper
bound on the wait for an ACK, i.e. an instruction to resend the message
if an ACK isn't received at *or before* the interval expiry ... with
that loose interpretation, an asserted RM BaseRetransmissionInterval of
500ms could be considered compatible with a previously asserted value of
250ms for an earlier invocation.

The idea would be to always efficiently determine if there's a
previously computed interceptor chain available for re-use, rather than
setting one up from scratch for each invocation.

To allow for the fact that the interceptor chains can be modified
in-flight (e.g. by removing interceptor(s) from the tail of the chain
during a message dispatch), I guess we'd need to clone the cached chain
for each new invocation.

Apologies if I'm showing my ignorance of WS-Policy with any of the above
suggestions ;) 

Cheers,
Eoghan


Mime
View raw message