Classification: UNCLASSIFIED Caveats: NONE Having finished the dev work for the delivery for end of March, I had a little time to pick up the Tuscany 2.0 prototype from where I left off. I finally got my policy interceptor hooked into the invocation chain (really hoped that there's a policy sample) and was able to see what actually goes on in the debugger. I mainly concentrated on the area of getting the SOAP envelope from reference and service sides. It's interesting to map what I saw to Simon's diagram - I appreciated the diagram even more, but at the same time I felt a little uneasy about some of issues, which may not be easy to fix. First, this is my configuration:
- Used Tuscany 2.0-Beta2 with Axis2 ws binding provider. I could not get the default JAX-WS provider to work. - Wrote a policy extension with a policy interceptor plugged in at reference/service binding phases. - Used Request/Response.getBindingContext() to access Axis2's OperationClient/MessageContext to obtain SOAPEnvelope. This is what I found: 1. <binding.ws requires="intent"> did not work for me. In the debugger, the composite builder did recognize the new policy and the fact that the reference/service has required intent, but matching check failed. However, <binding.ws policySets="policyset"> worked. 2. On the service side, my policy interceptor was called twice, once by RuntimeInvoker.invokeBinding() and once by DataTransformationInterceptor.invoke(). The latter baffled me because my policy.getPhase() returns service.binding.policy. 3. On the service side, after my policy's call to getNext().invoke() returns, the response (actually the same object as request) does not contain the response SOAP envelope (I did follow the context hierarchy to find the right message context for response). It has not been set up yet and it's null. I actually verified this by following the execution and found that the SOAP envelope is constructed after the call returned in Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(). This matches Simon's diagram comment number 1. What I felt uneasy about is the issue 3. It's not because the policy interceptor is invoked before Axis2 in the return direction, but because there seems to be no solution because of the single-point invocation chain architecture. Compared to the PolicyHandler's beforeInvoke() and afterInvoke() mechanism, which allows two (2) separate opportunities to plug in two logics at potentially two different places, the invocation chain mechanism has only one (1) callback, invoke(), which will need to call the "next". With this single-point mechanism, there seems to be a no-win situation - if you plug in policy interceptor at the point the diagram shows, the response envelope is not yet available for the outgoing response processing; but if you plug in policy interceptor at the point after responses envelope is constructed in Axis2, it'll be too late for the incoming request processing:-( Anyway, just want to bring up these issues so that they can be addressed before our project decides to move to Tuscany 2.0. BTW, when will the Tuscan 1.6.x next release with the fixes we have discussed be? Thanks, 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
