Classification: UNCLASSIFIED Caveats: NONE Hi, Simon,
Very good summary. My comments follow. Gang > -----Original Message----- > From: Simon Laws [mailto:simonsl...@googlemail.com] > Sent: Friday, February 25, 2011 12:18 PM > 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) > > Let me try that again with formatting and with 2.x comments.... > > > As previously discussed the 2,x binding specific interceptor model > is different from the 1.x model. Policy processing can intercept the > message flow in two places > > Generically on the operation specific wire > In a binding specific way on the binding wire > > The binding specific processing is free to (re-)configure the binding > as appropriate. For example it can add Axis handlers. Back to the > issues. This time with 2.x comments attached. > > > TUSCANY-3822 - Service side afterInvoker should be called with the > outbound Axis MC > Gang has correct the call to afterInvoke. Demonstrated in two > attachments to JIRA. There is some discussion of what the sequence > of calls should be for different MEPs, for example, > in-only: beforeInvoke(inMC) / afterInvoke(inMC) > in-out: beforeInvoke(inMC) / afterInvoke(outMC) > out-only: beforeInvoke(outMC) > Gang's summary comment > ====================== > 1. PolicyHandler.afterInvoke() needs to be called with the > outbound MessageContext instead of the inbound MC. > This is critical for WS-security. I have provided my fixes > in the JIRA. With some generalization we discussed, > I think this should be fixable in 1.6.x > 2.x comments > =========== > Binding interceptors have access to the binding context > which in the reference side is OperationClient which > holds "out" and "in" MessageContext. On the service > side it's the "in" MessageContext from which I believe you > can get the "out" MessageContext. We need to look whether > this asymmetry is necessary In addition to what is accessible, there's also a timing issue, which is also critical. Take the afterInvoke in 1.6.x as an example. Even though you may be able to get "out" MessageContext from "in" MessageContext, it's also critical when afterInvoke is called. Before my changes, afterInvoke is called at a time where "out" MessageContext has not been set up correctly. Conceptually, "out" MessageContext is more natural on the return direction. > > > TUSCANY-3838 - Reference side afterInvoke is skipped when AxisFault > occurs > Gang has corrected the call to afterInvoke in a patch attached to the > JIRA > Sub categories of this issue > 1. On the service side, any business exceptions from the > implementation > cause afterInvoke() to be skipped. Tuscany creates an AxisFault > wrapping the business exception, and throws this back to Axis2 > for it to generate the on-the-wire fault. > 2. On the service side, any system exceptions from the implementation > (e.g., ServiceRuntimeException) or from beforeInvoke() cause > afterInvoke() to be skipped. Tuscany creates an AxisFault by > calling > AxisFault.makeFault() and throws this back to Axis2 for it to > generate the on-the-wire fault. > 3. On the reference side, any AxisFault (either created by Axis2 or > created by Tuscany on the service side because of cases 1 or 2) > causes afterInvoke() to be skipped. > Gang's summary comment > ====================== > 4. PolicyHandler.afterInvoke is not called when Fault is > generated. So far, I have no workaround on this and would > like a fix. If I remember the code correctly, a quick fix is > possible if > Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() > can catch the exception, create the Fault body and call > PolicyHandler.afterInvoke() on the service side. I'm not sure > how > the client (requester) side works, but the > PolicyHandler.afterInvoke() > is also skipped on the return with the Fault. > 2.x comments > =========== > We're going to have to think through this one. We instigated a > pattern for the async work that we can potentially exploit. I'll > add faults to the test. The JIRA TUSCANY-3838 is only for the sub category 3 per Simon N.'s categorization. The other two don't have JIRA's yet. In the subsequent discussions, Simon and I had concluded that a fix for sub categories 1 & 2 are non-trivial because the actual AxisFault processing that creates the SOAPFault body happens much later on for afterInvoke to be invoked. But in 2.x, if a separate interceptor can be inserted on the return path, then this can be solved easily and naturally. > > TUSCANY-???? - Default dispatching mechanism in Axis depends on > looking at the wrapper element name > Gang added @WebMethod to the interfaces to drive the generation > of SOAPAction which Axis will use to select the service operation > The alternative is to use MessageContext.setSoapAction() in the > interceptor that does the encryption > Gang's summary comment > ====================== > 2. SOAP message encryption is not supported because the > PolicyHandler.beforeInvoke() is called after Axis2 dispatching > phase, which needs to analize SOAP body in order to determine > the endpoint method. This can be worked around by defining > SOAPaction in WSDL or Java interface using @WebMethod. > However, a future fix is still nice to have. > 2.x comments > =========== > I need to run some experiments on this but it looks like the > TuscanyDispatcher in 2.x is coded to dispatch off the URL. I don't > know under what circumstances this is used and whether we > support other dispatching mechanisms I think the take-away from this issue is that we need to be able to insert security interceptors fairly close to the transport. Ideally, there's not interceptors/processing that would alter the SOAP message between the two security interceptors (the one on client side and the one on the service side). This is because message encryption and signing. > > > TUSCANY-???? - We need to be able to pass context "through" a > component implementation so, for example, the security context > established when a service is called is available to references > of that service. > (1) service binding.ws -> > (2) handlers -> > (3) component implementation -> > (4) handlers -> > (6) reference binding.ws > Lots of discussion see, for example, > http://www.mail-archive.com/dev@tuscany.apache.org/msg15581.html > Gang's summary comment > ====================== > 3. A state-sharing mechanism is needed to allow sharing states > among service side interceptors/handlers, component and > reference side interceptors/handlers. I'm currently using the > ThreadLocal as a workaround, which I wish to have your blessing > - for now, it's only used from the service handler to component > and then to reference handler and I hope you can confirm that > the same thread is used for processing. However, we all agreed > that this is not desirable to use ThreadLocal in the service > framework and a state-sharing mechanism is needed. > 2.x comments > =========== > The problem remains. We need to bring all the ideas together > into a proposal > > > TUSCANY-???? - Where should interceptors be looking for message > information. Axis MC, Tuscany Message or both and should > the interceptor be fixing up the relationship between the two when > encrypting/decrypting > 2.x comments > =========== > In 2.x he binding chain is binding specific so has the opportunity > to do whatever it needs to do with both structures. We would expect > the writier of one of these interceptors to understand both Axis > and > Tuscany internals. Ideally, with good abstractions, the Tuscany interceptors don't have to understand other provider-specific implementations. However, in reality, this is often hard to achieve, especially for an SCA framework like Tuscany, which is so extensible to brings various implementations and protocols together. For WS-security, I need to access SOAP message, which is available from Axis2's MessageContext or JAX-WS's MessageContext depending on the underlying provider. But for other message protocols, one may need to access other provider's message context. I would think the main message context of Tuscany interceptors should be Tuscany's own. From Tuscany's message context, one should be able to retrieve ANY underlying implementation's message context. There should be an API to determine the underlying implementation so interceptors can take appropriate actions. Just my 2 cents. > > Gang, you offered to send in you 2.0 policy prototype code a one stage > in the various conversations. Could you do this bay attaching it to a > new JIRA? Unlike 1.6.x, my 2.0 interceptor prototype was very primitive. I was stuck early on trying to have Tuscany to recognize the new policy. I definitely can send you that if you think it can be of help. What may be more helpful is when I start to put more logic in the interceptor's invoke(). However, the goal for me is to obtain access to the SOAP message. > > Regards > > Simon > > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
