tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Laws <simonsl...@googlemail.com>
Subject Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Date Wed, 02 Feb 2011 09:57:39 GMT
On Wed, Feb 2, 2011 at 9:17 AM, Simon Nash <nash@apache.org> wrote:
> Simon Nash wrote:
>> Yang, Gang CTR US USA wrote:
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>> Simon,
>>> For bare mode, if you don't populate SOAPAction, how is the service side
>>> going to determine the endpoint method?
>> The difference seems to be that the JAX-WS RI generates WSDL with a global
>> element name and message part name that are the same as the operation
>> name.
>> Tuscany generates WSDL with a global element name and message part name
>> of arg0, so it needs to add SOAPAction to provide the operation name.
>> The JAX-WS specification says that the global element name and message
>> part name must be the same as the operation name, so Tuscany doesn't
>> conform to JAX-WS in the WSDL that it generates for bare operations.
>> I'll raise a JIRA for this.
>> Is there any reason why Tuscany shouldn't use the correct JAX-WS mapping
>> and remove the nonstandard addition of SOAPAction?
>>> On the same topic, I did the work-around you and Scott suggested - to
>>> use @WebMothod to force Tuscany to populate SOAPAction. It worked with
>>> some extra code I had to add to my PolicyHandler.
>>> The code that I had to add is to also modify the Tuscany internal
>>> Message that is also passed into beforeInvoke() after the decryption is
>>> done. My original code was only modifying the SOAP envelope in the
>>> MessageContext. I had to do this because the Message was set to use the
>>> SOAP body before calling PolicyHandler in
>>> Axis2ServiceProvider.invokeTarget() and it did not work correctly when
>>> it was used to call the endpoint via wire.invoke().
>>> Now should the code that modifies the Tuscany internal Message be done
>>> in my PolicyHandler code or be pulled back to Tuscany framework to hide
>>> the relations between MessageContext/envelope and Message? To me, it
>>> wasn't obvious how Message is related to MessageContext/envelope until I
>>> looked at Tuscany's code. This implementation can change in the future
>>> w/o PolicyHandler developer's knowledge. I'm wondering how others think.
>> There's a commented out call to beforeInvoke() at line 66 in
>> Axis2ServiceInOutSyncMessageReceiver, which would do what you are
>> suggesting.  This call would run before Tuscany's Message object is
>> constructed, so your code would only need to manipulate the Axis2
>> MessageContext and Tuscany would build the correct Message object
>> from that.
>> I don't know the history of why this call was commented out and
>> replaced by the other beforeInvoke() call in Axis2ServiceProvider.
>> There's also a matching commented out afterInvoke() call at line 74
>> of Axis2ServiceInOutSyncMessageReceiver, together with a pair of
>> similar commented out calls in Axis2ServiceInMessageReceiver.
>> Does anyone know the history of why these other calls to beforeInvoke()
>> and afterInvoke() were commented out?

I don't remember precisely why these specific calls were moved but it
was part of the wider move to work out what to do about configuring
bindings based on policy. Ultimately we introduced the notion of a
binding wire to host interceptors rather than relying these policy
handlers. We have this in binding.jms in 1.x and 2.x and we're on the
way to that for binding.ws in 2.x. The objective being to allow
interceptors to be introduced in amongst the binding implementation
using a mechanism that's consistent across bindings.

If moving these back to where they originally were helps in this
particular case then we should just do it.

I do intend to look at what implications this thread holds for 2.x but
haven't go to it yet.

Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

View raw message