> -----Original Message----- > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > Sent: 15 January 2007 09:21 > To: [email protected] > 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
