Classification: UNCLASSIFIED Caveats: NONE My response prefixed with "GY:".
-----Original Message----- From: Simon Nash [mailto:n...@apache.org] Sent: Wednesday, February 02, 2011 7:18 AM To: dev@tuscany.apache.org Subject: Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED) Simon Nash wrote: > Yang, Gang CTR US USA wrote: >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> Scott, >> >> I probably will try the @WebMethod as a workaround. But in general, if >> I'm programming in Tuscany as an end user, I should not have to rely on >> the knowledge of the internal implementation. What if the implementation >> changes? >> > That's a fair point. Would it be possible for the Tuscany Axis2 binding > to detect that the payload is encrypted and automatically add soapAction > to the generated WSDL? The confidentiality.message intent presumably > implies message-level encryption, but couldn't there be some other > user-defined intent that does message encryption without Tuscany knowing > that it's happening? > I think there's a fairly simple solution for this. The Axis2 MessageContext has a setSoapAction() method. It should be possible to call this in the policy handler that does the encryption (on the client side), so that Axis2 will send the SOAPAction header along with the encrypted message. With this approach, there's no need to pollute the SCA Java service interface with any implementation-specific information. GY: I tried this and it did work. But I prefer the @WebMethod approach as the workaround. Because as the handler, I'm not responsible for fixing the message routing problem and I don't always know if the destination service, which could be non-Tuscany, uses SOAPAction for dispatching. Using @WebMethod at least keeps it consistent on both client and service sides. Also don't forget the root cause of the issue, which is that the PolicyHandler method (at least for security) is invoke in the wrong position in the invocation chain in 1.6.1 Axis2 binding implementation. It should have been invoked before dispatching phrase, such as the security phase, which is where Rampart is placed. Simon > Simon > >> Thanks. >> Gang >> >> -----Original Message----- >> From: Scott Kurz [mailto:scottk...@gmail.com] Sent: Tuesday, February >> 01, 2011 12:35 PM >> To: dev@tuscany.apache.org >> Subject: Re: An issue with Axis2 WS binding dispatcher - the dispatching >> mechanism does not support SOAP message body encryption (UNCLASSIFIED) >> >> Gang, >> >> I see what you're saying... >> >> To recap, as Simon Nash mentioned, the default soapAction calculated >> from a Java method will be null, unless you annotate the Java method >> with: >> >> @WebMethod(action=....) >> >> So you're noting: >> >> - we can't do operation selection based on the payload, since it's >> encrypted >> - we can't do operation selection based on soapAction in the default, >> bottom-up (interface.java) case since the unannotated value defaults >> to null >> >> I'm not enough of an Axis2 expert to know if there is another >> dispatcher in the Axis2 world to help us out here. Maybe someone >> else does? >> >> But I agree it is an interesting point... as we go through a lot of >> trouble to enable the bottom-up case, and now, all of a sudden, you >> run into this case where unannotated Java can't be used with your >> function. But I don't have anything helpful to say on top of >> that.... >> >> Scott >> >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> >> >> > > > Classification: UNCLASSIFIED Caveats: NONE
