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

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

Expand Messages
  • graham glass
    hi there, i don t think that these representations need to be part of SOAP. i just think it would be great if the java guys agree on a format for encoding
    Message 1 of 80 , Jul 2, 2001
    • 0 Attachment
      hi there,

      i don't think that these representations need to be
      part of SOAP. i just think it would be great if the
      java guys agree on a format for encoding common java
      data structures. once a few do this, the others are
      likely to use the same format.

      this is what is already happening on a small scale.
      after all, there is no documentation that i'm aware
      of that says that a java int maps onto an XML schema
      int, etc.

      C++, C#, Perl guys, etc. can do whatever they want.
      they could decided to use the java mapping and map
      this onto their language, or use something else.
      ideally, the java<->xml schema mapping is language
      independent to improve the chances of this happening.


      -----Original Message-----
      From: Rosimildo daSIlva [mailto:rosimildo@...]
      Sent: Monday, July 02, 2001 5:14 PM
      To: soapbuilders@yahoogroups.com
      Subject: RE: [soapbuilders] Re: Where's decimal?

      --- Yann Christensen <yannc@...> wrote:
      > > Ideally, on the client side, no changes should be
      > needed. Maybe some
      > day.
      > You seem to be suggesting that SOAP should evolve to
      > not only describe a
      > wire format but also a programming API. I think that
      > would be a mistake.
      > Why should different programming
      > environments/languages have to adhere
      > to a common API? Undoubtedly you would end up with
      > some sort of least
      > common denominator feature set. I prefer for the
      > standards to focus on
      > the wire formats and let the toolkits decide how it
      > maps best into their
      > environment.
      > Now I think it is interesting to look at defining
      > recognizable patterns
      > for common complex data structures. Though I think
      > that would best occur
      > in XML Schema since that defines the common type
      > system across the
      > various toolkits.

      I guess you have not seen the messy that BOA was...
      people maintain it, still have nightmares...

      I do not think these things belong to SOAP.
      SOAP is what it is. A wire level protocol.
      The same as IIOP is for CORBA.

      I can tell you want thing, I have been working on this
      area long enough, to dare to say, that in one way
      or the other, mapping from WSDL to programming
      languages will come. It is just a matter of time.
      I do not think that these mappings have anything
      to do with SOAP, maybe more with XML schema or

      Have a good one.


      Do You Yahoo!?
      Get personalized email addresses from Yahoo! Mail

      This group is a forum for builders of SOAP implementations to discuss
      implementation and interoperability issues. Please stay on-topic.

      To unsubscribe from this group, send an email to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • 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.