On Tue, Mar 1, 2011 at 4:51 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > 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.
Absolutely and we can already create Axis handlers from our policy providers if required. Although these are of course specific to Axis. > > 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. +1 and I think this is our default position at the moment. Still means we need to improve the way interceptors are positioned and the way that we share context but it will basically work now. > > 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. Glad to have the suggestions Gang! I'm thinking that looking back to our JAXWS base binding.ws may be the motivation for this kind of thing. I wonder whether we, Tuscany, should define yet another SPI for creating interceptors in the guts of the protocol implementation or whether we should rely on some existing and relatively accepted like JAXWS. What concerns we with trying to provide our own abstraction is that inside the handler we're going to have to manipulate the message and the context that surrounds it. Trying to wrap that would be a lot of work. JAXWS has already done that. If you look at the JAXWS extension that Axis provides you can get the JAXWS message context but you can't get the underlying Axis context from the JAXWS context. Hence they are abstracting you away from how Axis physically process the JAXWS message under the convers. > > Gang > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
