You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by pierre post <pi...@secu.lu> on 2008/04/14 14:23:30 UTC

Qualified/unqualified namespace interoperability problem

Hi all,

I have an interoperability problem when calling an Apache CXF Web 
service (CXF version is 2.0.4) running under Apache Tomcat 6 from a VBA 
client program using MS Office 2003 Web Services Toolkit 2.03. When 
sending a request from the VBA client to the server, the response fails 
with the fault "Found element {http://annuaire.ciss.lu}questions but 
could not find matching RPC/Literal part". If I'm correct, the VBA 
client sends the request using qualified namespace for element 
"questions" but CXF expects an unqualified namespace. Due to technical 
constraints, I have to use RPC/Literal encoding and cannot switch to 
e.g. Document/Literal.

This is my web service:

package lu.ciss.annuaire.services;

@WebService(name="SimpleServiceName", 
targetNamespace="http://annuaire.ciss.lu")
@SOAPBinding(style=Style.RPC)       
public interface SimpleService {
    @WebMethod(operationName="GetAnswers")
    @WebResult(name="answer")
    public String getAnswers(@WebParam(name="questions") String[] 
questions);
}

The VBA client sends the following request:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema"
    xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body>
        <SOAPSDK4:GetAnswers xmlns:SOAPSDK4="http://annuaire.ciss.lu">
            <SOAPSDK4:questions SOAPSDK3:arrayType="SOAPSDK1:string[5]"
                SOAPSDK3:offset="[1]" SOAPSDK2:type="SOAPSDK3:Array">
                <item>What?</item>
                <item>Why?</item>
                <item>Where?</item>
                <item>Who?</item>
                <item>When?</item>
            </SOAPSDK4:questions>
        </SOAPSDK4:GetAnswers>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

As you can see the "questions" parameter is qualified. I know of the 
@XmlSchema annotation that you can place in the packge-info.java, but I 
don't know how to set the elementFormDefault to "qualified" for the 
namespace "http://jaxb.dev.java.net/array". Moreover the problem remains 
the same when using only simple types (e.g. integers or strings) instead 
of an array: the elements describing the parameters are always 
qualified. Here is an extract of the WSDL:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:ns1="http://annuaire.ciss.lu"
    xmlns:ns2="http://jaxb.dev.java.net/array"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="SimpleServiceName"
    targetNamespace="http://annuaire.ciss.lu">
    <wsdl:types>
        <xs:schema xmlns="http://jaxb.dev.java.net/array"
            xmlns:xs="http://www.w3.org/2001/XMLSchema"
            attributeFormDefault="unqualified" 
elementFormDefault="unqualified"
            targetNamespace="http://jaxb.dev.java.net/array">
            <xs:complexType final="#all" name="stringArray">
                <xs:sequence>
                    <xs:element maxOccurs="unbounded" minOccurs="0"
                        name="item" nillable="true" type="xs:string" />
                </xs:sequence>
            </xs:complexType>
        </xs:schema>
    </wsdl:types>
    <wsdl:message name="GetAnswers">
        <wsdl:part name="questions" type="ns2:stringArray"></wsdl:part>
    </wsdl:message>
    <wsdl:message name="GetAnswersResponse">
        <wsdl:part name="answer" type="xsd:string"></wsdl:part>
    </wsdl:message>
    <wsdl:portType name="SimpleServiceName">
        <wsdl:operation name="GetAnswers">
            <wsdl:input message="ns1:GetAnswers" name="GetAnswers">
            </wsdl:input>
            <wsdl:output message="ns1:GetAnswersResponse"
                name="GetAnswersResponse">
            </wsdl:output>
        </wsdl:operation>
    </wsdl:portType>
</wsdl:definitions>

Can anyone confirm that the problem originates from the fact that 
elementFormDefault is set to "unqualified" and setting it to "qualified" 
could solve the problem? If so, how is it possible to instruct CXF in 
general that parameter elements are always qualified?

Moreover, perhaps someone uses CXF with the MS Web services toolkit and 
can share his experiences with me? Unfortunately, the toolkit seems 
quite buggy ... :-(

Thank you very much for any comments.

Best regards,
Pierre


 



Re: Qualified/unqualified namespace interoperability problem

Posted by Daniel Kulp <dk...@apache.org>.
Pierre,

The WSI-Basic Profile specifically states that in RPC/Literal, the part 
accessor elements are ALWAYS to be unqualified.  This is per WSI-BP 
spec.   Basically, in RPC/Literal, the "wrapper" element (operationName) 
is qualified, the part accessor elements are unqualified, and the 
subelements of the parts are controlled by the schema.


>         <SOAPSDK4:GetAnswers xmlns:SOAPSDK4="http://annuaire.ciss.lu">
>             <SOAPSDK4:questions
> SOAPSDK3:arrayType="SOAPSDK1:string[5]" SOAPSDK3:offset="[1]"
> SOAPSDK2:type="SOAPSDK3:Array"> <item>What?</item>

This looks like the VBA client is generating a RPC/Encoded message, not 
an RPC literal.  The SOAPSDK3:arrayType attribute is the key.   That 
would only be there for an Encoded message.   CXF doesn't support 
RPC/Encoded.

Dan



On Monday 14 April 2008, pierre post wrote:
> Hi all,
>
> I have an interoperability problem when calling an Apache CXF Web
> service (CXF version is 2.0.4) running under Apache Tomcat 6 from a
> VBA client program using MS Office 2003 Web Services Toolkit 2.03.
> When sending a request from the VBA client to the server, the response
> fails with the fault "Found element {http://annuaire.ciss.lu}questions
> but could not find matching RPC/Literal part". If I'm correct, the VBA
> client sends the request using qualified namespace for element
> "questions" but CXF expects an unqualified namespace. Due to technical
> constraints, I have to use RPC/Literal encoding and cannot switch to
> e.g. Document/Literal.
>
> This is my web service:
>
> package lu.ciss.annuaire.services;
>
> @WebService(name="SimpleServiceName",
> targetNamespace="http://annuaire.ciss.lu")
> @SOAPBinding(style=Style.RPC)
> public interface SimpleService {
>     @WebMethod(operationName="GetAnswers")
>     @WebResult(name="answer")
>     public String getAnswers(@WebParam(name="questions") String[]
> questions);
> }
>
> The VBA client sends the following request:
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <SOAP-ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema"
>     xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/"
>     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
>     <SOAP-ENV:Body>
>         <SOAPSDK4:GetAnswers xmlns:SOAPSDK4="http://annuaire.ciss.lu">
>             <SOAPSDK4:questions
> SOAPSDK3:arrayType="SOAPSDK1:string[5]" SOAPSDK3:offset="[1]"
> SOAPSDK2:type="SOAPSDK3:Array"> <item>What?</item>
>                 <item>Why?</item>
>                 <item>Where?</item>
>                 <item>Who?</item>
>                 <item>When?</item>
>             </SOAPSDK4:questions>
>         </SOAPSDK4:GetAnswers>
>     </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
> As you can see the "questions" parameter is qualified. I know of the
> @XmlSchema annotation that you can place in the packge-info.java, but
> I don't know how to set the elementFormDefault to "qualified" for the
> namespace "http://jaxb.dev.java.net/array". Moreover the problem
> remains the same when using only simple types (e.g. integers or
> strings) instead of an array: the elements describing the parameters
> are always qualified. Here is an extract of the WSDL:
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <wsdl:definitions xmlns:ns1="http://annuaire.ciss.lu"
>     xmlns:ns2="http://jaxb.dev.java.net/array"
>     xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> name="SimpleServiceName" targetNamespace="http://annuaire.ciss.lu">
>     <wsdl:types>
>         <xs:schema xmlns="http://jaxb.dev.java.net/array"
>             xmlns:xs="http://www.w3.org/2001/XMLSchema"
>             attributeFormDefault="unqualified"
> elementFormDefault="unqualified"
>             targetNamespace="http://jaxb.dev.java.net/array">
>             <xs:complexType final="#all" name="stringArray">
>                 <xs:sequence>
>                     <xs:element maxOccurs="unbounded" minOccurs="0"
>                         name="item" nillable="true" type="xs:string"
> /> </xs:sequence>
>             </xs:complexType>
>         </xs:schema>
>     </wsdl:types>
>     <wsdl:message name="GetAnswers">
>         <wsdl:part name="questions"
> type="ns2:stringArray"></wsdl:part> </wsdl:message>
>     <wsdl:message name="GetAnswersResponse">
>         <wsdl:part name="answer" type="xsd:string"></wsdl:part>
>     </wsdl:message>
>     <wsdl:portType name="SimpleServiceName">
>         <wsdl:operation name="GetAnswers">
>             <wsdl:input message="ns1:GetAnswers" name="GetAnswers">
>             </wsdl:input>
>             <wsdl:output message="ns1:GetAnswersResponse"
>                 name="GetAnswersResponse">
>             </wsdl:output>
>         </wsdl:operation>
>     </wsdl:portType>
> </wsdl:definitions>
>
> Can anyone confirm that the problem originates from the fact that
> elementFormDefault is set to "unqualified" and setting it to
> "qualified" could solve the problem? If so, how is it possible to
> instruct CXF in general that parameter elements are always qualified?
>
> Moreover, perhaps someone uses CXF with the MS Web services toolkit
> and can share his experiences with me? Unfortunately, the toolkit
> seems quite buggy ... :-(
>
> Thank you very much for any comments.
>
> Best regards,
> Pierre



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog