On Wed, Mar 2, 2011 at 3:54 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > --- Cut --- >> >> Absolutely and we can already create Axis handlers from our policy >> providers if required. Although these are of course specific to Axis. > > Really? Are you saying that I, as a policy extension developer, can > write my own Axis2 handlers and tell Tuscany via policy extension > artifacts to add them to the Axis2 framework in the Axis2 WS binding > provider? Can you provide a pointer to how this can be done? I guess I > did not know this when I was prototyping policy extension in 2.0-Beta.
Yep, the policy providers get the opportunity to see binding specific configuration. You have to know what binding you're dealing with of course and in the ws/axis case it's an Axis2BaseBindingProvider object that the policy provider sees. Once you have that you can get at the Axis ConfigurationContext and you're off to the races. See http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSServicePolicyProvider.java We may need to work on that interface a bit but you get the idea, Other policies need to do other things with the configuration such as turning on MTOM but without access to the whole context it's difficult to predict what a policy might need to do. > >> > >> > 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. >> > > I agree the way I described was not desirable/feasible because Tuscany > has to be aware of each new provider type and has to add code to do the > wrapping and abstraction for each individually. To avoid this, we can > push the wrapping and abstraction to the WS binding provider side since > the provider knows their implementation as well as Tuscany's SPI. To do > this, a WS binding SPI, addHandler(Interceptor), can be added take a > Tuscany Interceptor, wrap it in the provider's native handler and add > the handler. > > The reason I mentioned these approach is to generalize the mechanism for > all WS binding providers. This is possible because all parties involved > here has a common base, which is the SOAP. Maybe there's other better > ways to do this, which can move the abstraction closer toward SOAP. OK, interesting, this would be a generic alternative to getting in and manipulating the Axis configuration directly (in the Axis case). I still come back to thinking isn't this what JAXWS is supposed to do but maybe I need to give it some more thought. > > Gang > > > Classification: UNCLASSIFIED > Caveats: NONE > > > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
