Classification: UNCLASSIFIED Caveats: NONE The picture is worth thousands of words. Thanks, Simon. It really helps understanding the architecture and thinking process.
I think the basic approach of treating Axis2 or other (JAX-WS, JAX-RPC etc.) binding provider module as a building block is a normal practice. The issue is that some special capabilities extensions needs to get in the middle of that building block. Luckily most, if not all, WS frameworks do provide a mechanism to allow access to their operation context and insertion of logic into their invocation chain - Axis, Axis2, JAX-WS and JAX-RPC all provide handlers and CXF provides interceptor. A simple approach can be to provide a Tuscany API to take an underlying provider's handler/interceptor written by the extension developer and register it with the underlying framework. But it does not hide the underlying provider's implementation from the extension developer. Another more sophisticated approach, which could potentially hide the underlying framework, could be to map the Tuscany's interceptors to the underlying binding provider's handlers as I mentioned earlier. On the high level, this could involve the following: - A WS binding SPI that would allow Tuscany to inquire about the underlying provider type so Tuscany knows what type of handlers to create, say Axis2 or JAX-WS. - A WS binding SPI that would allow Tuscany to register a handler with the underlying provider's framework. - When the policy extension definition is processed that requires insertion of logic into the binding provider's invocation chain, Tuscany creates a corresponding underlying framework handler, which wraps the extension's interceptor, and registers it with the underlying framework. - This underlying framework handler is created such that when called by the underlying framework, it will call the extension's interceptor invoke() method with the underlying framework's message context wrapped in Tuscany's generic message context for the extension's interceptor to access. - Similar extension SPI/API should be provided so that the extension developer can determine the type of the underlying framework, retrieve the corresponding message context and process accordingly. Hust some thoughts in a hope to help. Gang > -----Original Message----- > From: Simon Laws [mailto:simonsl...@googlemail.com] > Sent: Tuesday, March 01, 2011 5:17 AM > To: dev@tuscany.apache.org > Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler exception > handling issue - PolicyHandler.afterInvoke() is not called when > SOAPFault is generated (UNCLASSIFIED) > > 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+Implemen > tation > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
