Classification: UNCLASSIFIED Caveats: NONE Hi, Scott and Simon,
Thanks for the replies. My apology if I did not describe the issue clearly - I was trying to avoid lengthy descriptions since I'm posting to the dev group. Let me first clarify that there's nothing wrong with Axis2's framework. It by itself works fine. It's when Axis2 is used to provide the WS binding and the binding is trying to provide some extension capability, the architecture does not seem to support certain scenarios, such as the SOAP message body encryption. For the testing applications, I'm using straight Tuscany - a Tuscany 1.6.1 client launched using JSE and a Tuscany 1.6.1 service packaged in a war and deployed into JBoss. They both use WS binding (binding.ws). The service uses the Java interface and let Tuscany generate the necessary artifacts including WSDL. My main objective is to provide WS-Security using Tuscany's extension capability. So I followed Simon L.'s suggestion and wrote a PolicyHandler to intercept the SOAP. Everything else went fine (with minor changes to Tuscany code). With the SOAP message encryption, the PolicyHandler encrypts the body in the client side w/o problem. The problem occurs on the service side. This is what I think is going on: - The Axis2, as the WS binding provider, receives the request and processes the request using Axis2's framework which invokes the chain of handlers grouped in phases. One of its goal is to determine the endpoint and the endpoint method to be invoked and it's being done by several handlers (the class name uses xxxDispatcher) including one to determine the method using SOAPAction and one using the SOAP body. Since SOAPAction is not populated, the one using SOAP body has to succeed or the call fails (I'm using SOAP 1.1). - In the case the SOAP body is not encrypted, Axis2 framework would have determined the endpoint and method and passes the call to the Tuscany's WS binding code, which will invoke PolicyHandlers if configured before and after invoking the endpoint method. - However, when the SOAP body is encrypted, Axis2 would fail to determine the method and therefore fail the call before Tuscany WS binding code is involved and before PolicyHandler has a chance to decrypt the SOAP body. I think it's an architecture level issue. I'm bring it up hoping there's a workaround and also provide a use case for the future design consideration. The reason I mentioned SOAPAction is that I saw there is a dispatcher that is designed to use SOAPAction to determine the endpoint method. Without in depth knowledge of Tuscany's internals, I'm just crying out loud what if on the client side, the WS binding provider always uses SOAPAction (in both bare and wrapped mode)... Thanks, Gang -----Original Message----- From: Simon Nash [mailto:n...@apache.org] Sent: Tuesday, February 01, 2011 3:56 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) Scott Kurz wrote: > Gang, > > I don't know the answer but I'm curious myself how the Axis2 > dispatcher works in this case. > > What are you expecting the SOAPAction header to be set to? Are you > referencing an existing WSDL defining SOAPAction on each of the > reference/service sides or are you having the Tuscany WS binding > generate the WSDL for you. What are you seeing on the wire in the > HTTP header? > > Scott > > Tuscany uses the JAX-WS Java to WSDL mapping when it generates WSDL. In this mapping, the default for soapAction is a null string. To add a soapAction to the WSDL binding operation, you can use the @WebMethod(action=....) annotation on the Java service interface method. Simon Classification: UNCLASSIFIED Caveats: NONE
