You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Yang, Gang CTR US USA" <ga...@us.army.mil> on 2011/01/31 23:30:27 UTC
An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Hi,
I'm continuing the effort to provide a WS-Security using the
PolicyHandler extension framework in 1.6.1. I've successfully added the
capabilities to attach security tokens and to sign message body/headers
after I've modified the PolicyHandler framework code to allow
afterInvoke() to be called with the outbound MessageContext (please see
http://www.mail-archive.com/dev@tuscany.apache.org/msg15425.html for
details, which contains my latest post asking for the next release
information and help to include my changes. I would really appreciate it
if someone respond to it). Now I've encountered another problem trying
to encrypt the SOAP message body.
The problem has to do with the dispatching mechanism used by Axis2 WS
binding implementation and the order the PolicyHandler.beforeInvoke() is
called relative to the dispatcher.invoke. That dispatching
implementation relies on the SOAP message body content (the 1st element
as the method in the wrapped mode) to determine the endpoint method to
invoke. At the same time, PolicyHandler.beforeInvoke() is call after the
dispatcher.invoke(). So if the message body is encrypted by the client
and would be decrypted only by PolicyHandler.beforeInvoke() (the
extension), then dispatcher.invoke would not be able to determine the
endpoint method to invoke.
Is there a way I can work around the current design? Why wasn't
SOAPAction populated so that it can be used to dispatch the message?
Thanks in advance.
Gang
Classification: UNCLASSIFIED
Caveats: NONE
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
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
RE: An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
My response prefixed with "GY:".
-----Original Message-----
From: Simon Nash [mailto:nash@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:scottkurz@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
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
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.
Simon
> Simon
>
>> Thanks.
>> Gang
>>
>> -----Original Message-----
>> From: Scott Kurz [mailto:scottkurz@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
>>
>>
>>
>>
>
>
>
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
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?
Simon
> Thanks.
> Gang
>
> -----Original Message-----
> From: Scott Kurz [mailto:scottkurz@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
>
>
>
>
RE: An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
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?
Thanks.
Gang
-----Original Message-----
From: Scott Kurz [mailto:scottkurz@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
Re: An issue with Axis2 WS binding dispatcher - the dispatching
mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Scott Kurz <sc...@gmail.com>.
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
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Hi Gang,
Thanks for the detailed explanation. See comment inline below.
Simon
Yang, Gang CTR US USA wrote:
> 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)...
>
You should be able to add the necessary SOAPAction headers by using
the @WebService(action=....) annotation in your Java service interface.
If you don't specify this annotation, it would be incorrect for Tuscany
to add SOAPAction because this would contravene the JAX-WS specification.
Can you try doing this and see if it solves the problem?
Simon
> Thanks,
> Gang
>
> -----Original Message-----
> From: Simon Nash [mailto:nash@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
>
>
>
>
RE: An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
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:nash@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
Re: An issue with Axis2 WS binding dispatcher - the dispatching
mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Feb 2, 2011 at 9:17 AM, Simon Nash <na...@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.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
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 checked back to see when this change was made. It was part of
r692411 (slaws, 5 Sept 2008). The commit comment says:
Use basic authentication as a motivating scenario for looking at policy plug points.
Generic username/password processing is added as an interceptor. Specific axis
configuration is performed by new logic specific to binding.ws which is invoked if
the basic auth policy is present (we need to think about this mechanism). I added a
binding-ws-axis2-policy module as a replacement for policy-security-ws but haven't
moved over to it yet. I also added a message header map to Message but have only
been experimenting to date.
There's a bit of discussion on the dev list preceding this, and a pointer to
a wiki page, but I can't find anything saying why the policy handler calls were
moved from Axis2ServiceInOutSyncMessageReceiver and Axis2ServiceInMessageReceiver
to Axis2ServiceProvider. Any insights on the motivation for this change would
be much appreciated.
Simon
> Simon
>
>> Thanks to Simon and Scott's suggestion.
>> Gang
>>
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org] Sent: Tuesday, February 01,
>> 2011 3:23 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)
>>
>> Simon Nash wrote:
>>> Scott Kurz wrote:
>>>> Ah, thanks Simon for reminding us of that. I'd remembered us
>>>> generating a soapAction anyway.. but that's just for the bare mapping
>>>> apparently.
>>>>
>>>>
>>> I saw that code, and I was rather puzzled by it as I didn't see
>>> anything in the JAX-WS spec to say that SOAPAction should be
>>> generated in the bare mapping case.
>>>
>>> Perhaps I should run a couple of Java interfaces (bare and wrapped)
>>> through the JAX-WS RI wsgen to see what it does with them.
>>>
>> I tried this, and wsgen doesn't seem to treat the bare case any
>> differently than the wrapped case. In both cases soapAction is
>> generated only if specified by @WebMethod(action=....)
>>
>> Why does Tuscany always generate soapAction for the bare case,
>> even though this is inconsistent with JAX-WS?
>>
>> Simon
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>>
>
>
>
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
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?
Simon
> Thanks to Simon and Scott's suggestion.
> Gang
>
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Tuesday, February 01, 2011 3:23 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)
>
> Simon Nash wrote:
>> Scott Kurz wrote:
>>> Ah, thanks Simon for reminding us of that. I'd remembered us
>>> generating a soapAction anyway.. but that's just for the bare mapping
>>> apparently.
>>>
>>>
>> I saw that code, and I was rather puzzled by it as I didn't see
>> anything in the JAX-WS spec to say that SOAPAction should be
>> generated in the bare mapping case.
>>
>> Perhaps I should run a couple of Java interfaces (bare and wrapped)
>> through the JAX-WS RI wsgen to see what it does with them.
>>
> I tried this, and wsgen doesn't seem to treat the bare case any
> differently than the wrapped case. In both cases soapAction is
> generated only if specified by @WebMethod(action=....)
>
> Why does Tuscany always generate soapAction for the bare case,
> even though this is inconsistent with JAX-WS?
>
> Simon
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
>
RE: An issue with Axis2 WS binding dispatcher - the dispatching mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
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?
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.
Thanks to Simon and Scott's suggestion.
Gang
-----Original Message-----
From: Simon Nash [mailto:nash@apache.org]
Sent: Tuesday, February 01, 2011 3:23 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)
Simon Nash wrote:
> Scott Kurz wrote:
>> Ah, thanks Simon for reminding us of that. I'd remembered us
>> generating a soapAction anyway.. but that's just for the bare mapping
>> apparently.
>>
>>
> I saw that code, and I was rather puzzled by it as I didn't see
> anything in the JAX-WS spec to say that SOAPAction should be
> generated in the bare mapping case.
>
> Perhaps I should run a couple of Java interfaces (bare and wrapped)
> through the JAX-WS RI wsgen to see what it does with them.
>
I tried this, and wsgen doesn't seem to treat the bare case any
differently than the wrapped case. In both cases soapAction is
generated only if specified by @WebMethod(action=....)
Why does Tuscany always generate soapAction for the bare case,
even though this is inconsistent with JAX-WS?
Simon
Classification: UNCLASSIFIED
Caveats: NONE
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Simon Nash wrote:
> Scott Kurz wrote:
>> Ah, thanks Simon for reminding us of that. I'd remembered us
>> generating a soapAction anyway.. but that's just for the bare mapping
>> apparently.
>>
>>
> I saw that code, and I was rather puzzled by it as I didn't see
> anything in the JAX-WS spec to say that SOAPAction should be
> generated in the bare mapping case.
>
> Perhaps I should run a couple of Java interfaces (bare and wrapped)
> through the JAX-WS RI wsgen to see what it does with them.
>
I tried this, and wsgen doesn't seem to treat the bare case any
differently than the wrapped case. In both cases soapAction is
generated only if specified by @WebMethod(action=....)
Why does Tuscany always generate soapAction for the bare case,
even though this is inconsistent with JAX-WS?
Simon
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
Scott Kurz wrote:
> Ah, thanks Simon for reminding us of that. I'd remembered us
> generating a soapAction anyway.. but that's just for the bare mapping
> apparently.
>
>
I saw that code, and I was rather puzzled by it as I didn't see
anything in the JAX-WS spec to say that SOAPAction should be
generated in the bare mapping case.
Perhaps I should run a couple of Java interfaces (bare and wrapped)
through the JAX-WS RI wsgen to see what it does with them.
Simon
Re: An issue with Axis2 WS binding dispatcher - the dispatching
mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Scott Kurz <sc...@gmail.com>.
Ah, thanks Simon for reminding us of that. I'd remembered us
generating a soapAction anyway.. but that's just for the bare mapping
apparently.
Re: An issue with Axis2 WS binding dispatcher - the dispatching mechanism
does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Simon Nash <na...@apache.org>.
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
Re: An issue with Axis2 WS binding dispatcher - the dispatching
mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Posted by Scott Kurz <sc...@gmail.com>.
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