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

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

Expand Messages
  • Yann Christensen
    ... 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
    Message 1 of 80 , Jul 2, 2001
    • 0 Attachment
      > 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.

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

      > i think it would also be good to come up with
      > some standard WSDL bindings for the common Java
      > structures, such as Vector and Hashtable, that at
      > least
      > the Java platforms can agree upon. i know that the
      > developer community would appreciate this.
      >
      > perhaps the apache, GLUE, WASP, etc. teams can
      > work on this together?
      >

      I think this is a very important aspect. I am
      not sure if understand what you mean by
      "binding". <g>

      But, if you mean by it, a standard way of mapping to
      languages such as C++/java, I would say it is very
      important. Something like OMG has done for CORBA.

      Today, if I decide to write an application using SOAP,
      the code is totally *toolkit dependent* because
      there is no "standard" way of mapping from WSDL to a
      particular language.

      If I start using Apache SOAP and decide to use GLUE,
      some code must be changed. Ideally, on the client
      side, no changes should be needed. Maybe some day.

      Rosimildo.





      __________________________________________________
      Do You Yahoo!?
      Get personalized email addresses from Yahoo! Mail
      http://personal.mail.yahoo.com/

      -----------------------------------------------------------------
      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:
      soapbuilders-unsubscribe@yahoogroups.com



      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
        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) 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>
        <faultactor>/soap/servlet/rpcrouter</faultactor>

        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
        working?

        Best Regards,
        Paul





        --- In soapbuilders@y..., "Alex DeJarnatt" <alexdej@m...> wrote:
        > Paul, I can address the 3 issues you encountered. However, only one
        of
        > them can be fixed on the .NET side...
        >
        > 1. the binding attribute of port and the type attribute of binding
        are
        > 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
        supports
        > this?
        >
        > 2. ASP.NET web services beta 2 support WSDL 1.1, which requires use
        of
        > 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
        the
        > rules of WSDL section 4, but it's reasonable to not want to include
        this
        > in your generated WSDL if you're not interested in using get or
        post.
        > 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
        directory
        > 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/",
        >
        ResponseNamespace="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
        current
        > 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>,
        > <binding type>, etc.
        >
        > - Different Levels of Support for XML Schema: .Net generates 2001
        XML
        > 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,
        so
        > 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.