Hi Gang Comments in line. Generally I still think the processing we have in 2.x is too late/early for you to get at the envelope to decrypt/encrypt it before the Axis2 engine has a go at it. It may be the answer is to map part of the handler chain into Axis2 handlers (as you have already done) rather than trying to do it all outside of Tuscany. I'll try and come up with a picture of what we have and map you issues onto it so we can look to improve 2.x
Regards Simon On Tue, Feb 22, 2011 at 5:00 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, Simon L., > > Forgot to ask. From what you described, it sounds promising in Tuscany 2.0 > using interceptors approach. Based on your quick assessment, how complete is > Tuscany 2.0 policy interceptor framework? Would it now support the four > capabilities I raised and summarized earlier in this thread? If not, would 1 > and 4 at least be supported and 2 and 3 be still working using the > workaround? Below is the list I copied from earlier post. Of course in the > interceptor approach, there wouldn't be before/afterInvoke(), but just > invoke, which would invoke the next in the invocation chain and adding logic > before and after the next.invoke(). > > 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. The binding chain isn't active on the service side yet so as we bring that up we'll have to look at providing the output MC on the response path. > > 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. Currently we're still relying on Axis2 dispatching but I note that we are plugging into the dispatching mechanism to pull the service name out of the target path [1]. We may need to make this part pluggable if you need to look inside the message body. > > 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. We need this generally, i.e. it's not particular to the ws binding. I'll look back at what we said before as IIRC the conclusion was that we needed more that just the single message context that's provided at present as it gets overwritten on the reference side. If we can make both the service and reference side messages available then those messages do have header and binding context slots that can be used. We need a coherent proposal to review here. I'll raise a JIRA. > > 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. The handlers should get in on the act for fault processing but I still think it will be too early re. access to the envelope. > > Thanks, > Gang [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-ws-runtime-axis2/src/main/java/org/apache/tuscany/sca/binding/ws/axis2/provider/TuscanyDispatcher.java -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
