I put a diagram of my understanding of the current 2.x binding.ws/policy interceptor situation here [1] along with some comments relating to the issues we've been discussing (the first four numbered comments relate to Gang's numbered comments). Some of these issues are I think resolvable given the approach to Axis integration we have at the moment. Some of them are more problematic though.
Our basic approach currently is that we do all of our processing outside of the Axis handlers. Our approach to WS-Security is to engaged Rampart (this is enabled in 1.x but not yet in 2,x) rather than to write it ourselves The requirement to process the SOAP message very close to the transport when doing bespoke encryption is the tricky part. To allow it all to happen in the binding wire using policy interceptors we'd have to be much more careful about where SOAP envelopes are created and read and where the operation selection is performed. There is a danger of re-inventing Axis. I think a sensible approach to making progress is to improve the things we should improve regardless of the bespoke encryption requirement. For example, 5/ consistency of binding context, 1/ access to appropriate message contexts, 2/ context sharing mechanism. The fallback for bespoke encryption is to create Axis handlers. In parallel I'd like to look at how we integrate with Axis, for example, we could look back at the JAXWS integration approach so at least any handlers that are build are in some way following a standard pattern. [1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy+Implementation Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
