6 Replies Latest reply on Feb 24, 2005 7:11 AM by Thomas Diesler

    JBoss ws-client - .NET interoperability issue

    siano Newbie

      Hi,

      I have an interoperability issue between a JBoss webservice client and a .NET webservice (which is located externally and which I cannot change).

      I have generated the client code and a test server implementation with wscompile from the provides wsdl file (with the wsi feature and the import option). My client and my test webservice work fine.

      However, if I try to access the external .NET webservice, it doesn't see any paramters.

      My message looks as follows

      <?xml version="1.0" encoding="UTF-8"?>
      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <soapenv:Body>
       <ns1:GetAllRoutingTargets xmlns:ns1="http://namespace.com/namespace/">
       <serviceNumber>string</serviceNumber>
       </ns1:GetAllRoutingTargets>
       </soapenv:Body>
      </soapenv:Envelope>
      


      The external party claims the message has to look like this:

      <?xml version="1.0" encoding="utf-8"?>
      <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body>
       <GetAllRoutingTargets xmlns="http://namespace.com/namespace/">
       <serviceNumber>string</serviceNumber>
       </GetAllRoutingTargets>
       </soap:Body>
      </soap:Envelope>
      


      These messages seem quite equivalent to me, the only difference is the ns1-prefix for the namespace.

      Since I cannot change the webservice. Is there a way to influence the behaviour of namespace handling in JBoss Webservices (e.g. some hack in ws4ee-deployment.xml)?

      Thanks for your input, since I am rather clueless how to proceed.

      Yours
      Stephan Siano

        • 1. Re: JBoss ws-client - .NET interoperability issue
          Ole Matzura Novice

          Hi!

          actually i think the requests are not equivalent from an xml-point-of-view.. in their case all elements are qualified, in your case only the root element is qualified.. probably their schema says that element names have to be qualified which is why your request doesnt work..

          jbossws seems to have problems with qualifying correctly.. one workaround I can think of is creating a nodatabinding client with wscompile and generating the request-xml "yourself" with the correct "qualifications".. (you could use for example XMLBeans for generating databinding-classes, works fine for us..)

          maybe I'm wrong.. anybody else?

          regards!

          /Ole

          • 2. Re: JBoss ws-client - .NET interoperability issue
            Andrew Wagg Newbie

            JBsss, well the AXIS component does not qualify the names correctly, as I found when asking earlier. You need a ws4ee-deployment.xml in your WEB-INF, this needs to include the gernated type mappings in the JBoss generated wsdd file. The for the type, change the xmlName to include your namespace.

            <typeMapping
             qname='ns1:ReplyItemList' xmlns:ns1='http://opcfoundation.org/webservices/XMLDA/1.0/'
             type='java:org.opcfoundation.webservices.XMLDA._1_0.ReplyItemList'
             serializer='org.jboss.webservice.encoding.ser.MetaDataBeanSerializerFactory'
             deserializer='org.jboss.webservice.encoding.ser.MetaDataBeanDeserializerFactory'
             encodingStyle=''>
             <typeDesc>
             <elementDesc fieldName='reserved' xmlName='Reserved' asAttr='true'/>
             <elementDesc fieldName='items' xmlName='ns1:Items'/>
             <elementOrder> <element name='items'/>
             </elementOrder> </typeDesc>
             </typeMapping>
            


            Hope this helps,

            Andy

            • 3. Re: JBoss ws-client - .NET interoperability issue
              siano Newbie

              Hi,

              I tried the following type mapping, but it didn't have any effect at all (the message looks exactly as it did before).

               <typeMapping
               qname='ns1:GetAllRoutingTargets' xmlns:ns1='http://namespace.com/namespace/'
               type='java:com.test.GetAllRoutingTargets'
               serializer='org.jboss.webservice.encoding.ser.MetaDataBeanSerializerFactory'
               deserializer='org.jboss.webservice.encoding.ser.MetaDataBeanDeserializerFactory'
               encodingStyle=''>
               <typeDesc>
               <elementDesc fieldName='serviceNumber' xmlName='ns1:serviceNumber' xmlns:ns1='http://namespace.com/namespace/'/>
               <elementOrder>
               <element name='serviceNumber'/>
               </elementOrder>
               </typeDesc>
               </typeMapping>
              


              I also found a namespace tag in the definition axis' wsdd-files. However the wsdd-file is generated somehow by jboss (among others from the ws4ee-deployment.xml), but I didn't manage to get this tag into the wsdd-file.

              It also seems that the targetNamespace attribute in the schema element of the wsdl-file is ignored.

              Is this behaviour correct?

              Stephan

              • 4. Re: JBoss ws-client - .NET interoperability issue
                Andrew Wagg Newbie

                In my case I would have done your type mapping as below and not have include a namespace in the element. Also. you could modify the log4j.xml configuration file to output the debug logging for Axis. You should then be able to check the JBoss log to ensure your type mapping has replaced the original. Your ws4ee-deployment.xml with these type mappings should be in your WEB-INF.

                 <typeMapping
                 qname='ns1:GetAllRoutingTargets' xmlns:ns1='http://namespace.com/namespace/'
                 type='java:com.test.GetAllRoutingTargets'
                 serializer='org.jboss.webservice.encoding.ser.MetaDataBeanSerializerFactory'
                 deserializer='org.jboss.webservice.encoding.ser.MetaDataBeanDeserializerFactory'
                 encodingStyle=''>
                 <typeDesc>
                 <elementDesc fieldName='serviceNumber' xmlName='ns1:serviceNumber' />
                 <elementOrder>
                 <element name='serviceNumber'/>
                 </elementOrder>
                 </typeDesc>
                 </typeMapping>
                


                Andy

                • 5. Re: JBoss ws-client - .NET interoperability issue
                  siano Newbie

                  Thanks for your help.

                  After I looked again into the generated wsdd file, I found that in addition to the (redefined) typeMapping with

                  qname='ns1:GetAllRoutingTargets'
                  

                  there was another typeMapping with
                  qname='ns1:>GetAllRoutingTargets'
                  

                  (which was otherwise identical to the other one).

                  After I changed that one in the way you proposed, too, it worked, so my problem is (hopefully) solved. (At least I was able to do some successful communication with the .NET server.)

                  Just for the record: Does anybody have a clue what this qname='ns1:>GetAllRoutingTargets' typeMapping is for?

                  Stephan

                  • 6. Re: JBoss ws-client - .NET interoperability issue
                    Thomas Diesler Master

                    The qname='ns1:>GetAllRoutingTargets' comes from the generated jaxrpc-mapping.xml which in turn maps XML schema types to Java classes.

                    If the schema contains anonymous types like this

                    <element name="SomeName">
                     <complexType>
                     ....
                     </complexType>
                    </element>
                    


                    it needs to somehow give the contained complex type a name, which it does not have in the schema. Fo that it uses the '>' notation.

                    For details see the JSR-109 specification.