Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Re: Where's decimal?

Expand Messages
  • Sam Ruby
    ... Sounds good to me. I d actually like to see as many as possible... duration, byte, short, etc. - Sam Ruby
    Message 1 of 80 , Jul 2, 2001
    • 0 Attachment
      > I'd like to see boolean... it has interesting lexical aspects.

      Sounds good to me. I'd actually like to see as many as possible...
      duration, byte, short, etc.

      - Sam Ruby
    • Paul Welch
      Alex, Thanks for the tip, the web.config entry worked great. I m now trying to get a .Net (beta 2) client calling a very simple helloworld Apache SOAP (v2.2)
      Message 80 of 80 , Jul 20, 2001
      • 0 Attachment

        Thanks for the tip, the web.config entry worked great.

        I'm now trying to get a .Net (beta 2) client calling a very simple
        helloworld Apache SOAP (v2.2) service with one string in and a string
        return. After jumping through many hoops already, I am close but
        still get this error:

        <faultcode>SOAP-ENV:Client</faultcode> <faultstring>No Deserializer
        found to deserialize a ':meth1_inType1' using encoding
        style 'http://schemas.xmlsoap.org/soap/encoding/'.</faultstring>

        The type attribute for meth1_inType1 is defined as xsd:string. The
        equivalent java client works fine and comparing the .net vs. java raw
        soap requests, there are only 2 differences. 1) 1999 vs. 2001 XML
        Schema namespaces and 2) the encodingStyle attribute is on the 'Body'
        tag vs. on the 'helloworld' (method) tag. I read in Apache's doc's
        that 2001 schema would be deserialized correctly, but haven't tested
        this myself. Also, haven't found a way to tell .Net to put the
        encodingStyle attribute on a different tag to test if that
        specifically causes the fault.

        Any suggestions as to how I can get this simple interoperability test

        Best Regards,

        --- In soapbuilders@y..., "Alex DeJarnatt" <alexdej@m...> wrote:
        > Paul, I can address the 3 issues you encountered. However, only one
        > them can be fixed on the .NET side...
        > 1. the binding attribute of port and the type attribute of binding
        > QNames. The generated WSDL is correct. That said, this seems to be a
        > common mistake -- a good number of the WSDLs on xmethods don't use
        > QNames. Perhaps there's a newer import tool you could use that
        > this?
        > 2. ASP.NET web services beta 2 support WSDL 1.1, which requires use
        > the 2001 XML Schema. Again, perhaps there's a newer import tool you
        > could get...
        > 3. the WSDL for get and post should be spec-compliant according to
        > rules of WSDL section 4, but it's reasonable to not want to include
        > in your generated WSDL if you're not interested in using get or
        > You can turn off support for GET and POST on a per-appdir basis by
        > putting the following in a file called web.config in the same
        > as your .asmx
        > <configuration>
        > <system.web>
        > <webServices>
        > <protocols>
        > <remove name="HttpGet"/>
        > <remove name="HttpPost"/>
        > </protocols>
        > </webServices>
        > </system.web>
        > </configuration>
        > alex
        > -----Original Message-----
        > From: Paul Welch [mailto:paulwelch28@y...]
        > Sent: Wednesday, July 11, 2001 2:21 PM
        > To: soapbuilders@y...
        > Subject: [soapbuilders] Re: .NET encoding stuff
        > I've been trying to work through the .Net to IBM WSTK WSDL
        > compatibility. I've made it all the way from .Net Web Service to a
        > working auto-generated java client proxy, but only with several
        > manual edits of the WSDL. I have a .Net service with the following
        > attributes specified:
        > at the class level:
        > [WebService(Namespace="http://www.divine.com/")]
        > [SoapRpcServiceAttribute(RoutingStyle =
        > SoapServiceRoutingStyle.SoapAction)]
        > and, at the method level:
        > [WebMethod]
        > [SoapRpcMethodAttribute( "http://www.divine.com/",
        > RequestNamespadce="http://www.divine.com/",
        > Even though it's generated in RPC style, the .Net WSDL still has
        > several incompatibilities with the IBM WSTK proxygen utility
        > (using .Net Studio beta 2 and IBM WSTK V2.3). The ones I've
        > identified so far are:
        > - Different Rules for Resolving Fully Qualified Definitions: For
        > instance, .Net creates a s0 namespace (tempuri.com by default) and
        > tries to qualify types to s0 that are actually defined in the
        > document. The proxygen does not appear to look in the current
        > document for fully qualified types. My solution so far has been to
        > delete "s0:" qualifications from these, including the <port
        > <binding type>, etc.
        > - Different Levels of Support for XML Schema: .Net generates 2001
        > Schema namespace, IBM WSTK expects 1999. So far, changing the WSDL
        > to 1999 has worked.
        > - HTTP Get/Post Support: I need to research this one further,
        > however proxygen does not accept the .Net generated definitions for
        > these. I was more interested in getting the SOAP binding to work,
        > I haven't spent much time on it yet.
        > I realize this is a short-term problem until the tools are more
        > mature, but are there any solutions that might be more elegant than
        > directly editing the WSDL, such as additional .Net attributes, etc.?
        > Thanks in advance for any suggestions...
        > Best Regards,
        > Paul
      Your message has been successfully submitted and would be delivered to recipients shortly.