You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jarek Gawor <jg...@gmail.com> on 2008/10/08 05:26:31 UTC

wsa:Action interop issue

Hi,

I ran into an interesting interop issue with wsa:Action between CXF
and JAX-WS RI (2.1.4). I have a simple service class, no sei, no
@Action annotations, something like:

@WebService
@Addressing
class Calculator {
 public int add(in n1, in2) {
   return n1 + n2;
 }
}

CXF generated the following wsdl:operation for the "add" method:

<wsdl:operation name="add">
    <wsdl:input message="tns:add" name="add"/>
    <wsdl:output message="tns:addResponse" name="addResponse"/>
</wsdl:operation>

JAX-WS RI generated the following wsdl:operation for the same method:

<operation name="add">
   <input message="tns:add"
wsaw:Action="http://geronimo.apache.org/calculator/Calculator/addRequest"/>
   <output message="tns:addResponse"/>
</operation>

Now, the wsa:Action for the CXF generated wsdl:operation would be
"http://geronimo.apache.org/calculator/Calculator/add", and for RI is
"http://geronimo.apache.org/calculator/Calculator/addRequest". Since
the wsa:Action are slightly different that might create an interop
problem. I couldn't really find that much info on this issue in the
JAX-WS spec but I assume if the @Action is not specified the default
algorithm (as defined in the WS-A spec) should be used. The wsa:Action
generated by the RI conforms to that algorithm.
So I think the CXF should either not add the "name" attribute to
wsdl:input/output messages or add in an explicit wsa:Action attribute
as the RI does.

Thoughts?

Jarek

Re: wsa:Action interop issue

Posted by Daniel Kulp <dk...@apache.org>.
I'm not sure what to say about this one.   Neither CXF or the RI are "wrong" 
here, they are both completely correct per the specifications. 

Putting the "name" there is definitely OK per JAX-WS spec and I definitely 
prefer keeping it there as certain tools sometimes have issues mapping things 
together without it.  (I got bit several times with older versions of wsdl4j)

If we were to generate a wsaw:Action on it, we would follow the rules in the 
WS-A spec for the case where the name is specified and it would be:
wsaw:Action="http://geronimo.apache.org/calculator/Calculator/add"
which is still different than what the RI would be.

In anycase, I think the "proper" thing to say here is "add an @Action 
annotation".   Make sure you completely control it.

Dan


On Tuesday 07 October 2008 11:26:31 pm Jarek Gawor wrote:
> Hi,
>
> I ran into an interesting interop issue with wsa:Action between CXF
> and JAX-WS RI (2.1.4). I have a simple service class, no sei, no
> @Action annotations, something like:
>
> @WebService
> @Addressing
> class Calculator {
>  public int add(in n1, in2) {
>    return n1 + n2;
>  }
> }
>
> CXF generated the following wsdl:operation for the "add" method:
>
> <wsdl:operation name="add">
>     <wsdl:input message="tns:add" name="add"/>
>     <wsdl:output message="tns:addResponse" name="addResponse"/>
> </wsdl:operation>
>
> JAX-WS RI generated the following wsdl:operation for the same method:
>
> <operation name="add">
>    <input message="tns:add"
> wsaw:Action="http://geronimo.apache.org/calculator/Calculator/addRequest"/>
>    <output message="tns:addResponse"/>
> </operation>
>
> Now, the wsa:Action for the CXF generated wsdl:operation would be
> "http://geronimo.apache.org/calculator/Calculator/add", and for RI is
> "http://geronimo.apache.org/calculator/Calculator/addRequest". Since
> the wsa:Action are slightly different that might create an interop
> problem. I couldn't really find that much info on this issue in the
> JAX-WS spec but I assume if the @Action is not specified the default
> algorithm (as defined in the WS-A spec) should be used. The wsa:Action
> generated by the RI conforms to that algorithm.
> So I think the CXF should either not add the "name" attribute to
> wsdl:input/output messages or add in an explicit wsa:Action attribute
> as the RI does.
>
> Thoughts?
>
> Jarek



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog