See responses below. I've removed older discussion to make this
easier to follow.
Simon
Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED
Caveats: NONE
My response prefixed with "GY:".
>
(cut)
>
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.
>
OK, that makes sense, as the handler approach won't put soapAction
into the WSDL. One further option is to manually generate WSDL from
the Java interface, add soapAction to the generated WSDL, and reference
the generated WSDL in the SCA service and reference bindings. This
ensures that the service WSDL matches what is sent on the wire, while
keeping the Java business interface unpolluted by implementation
artifacts.
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.
I undersand what you're saying, but this would be quite a big change
to the Tuscany implementation and I don't think it's likely to get into
the 1.x codebase. This would be a good topic for discussion for the
2.0 implementation.
Simon
