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

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

Expand Messages
  • Glen Daniels
    I agree this is important, and the general issue of Schema Language bindings is a fascinating one. For now, I think just focusing on basic collection types
    Message 1 of 80 , Jul 2, 2001
      I agree this is important, and the general issue of Schema<->Language
      bindings is a fascinating one. For now, I think just focusing on basic
      collection types would be a good step in the right direction, though.

      For anything in Java that implements List, I think the natural serialization
      is a SOAP array. Then it's up to the tools on either side to correctly
      translate between whatever linear-ordinal-collection class you have to/from
      SOAP arrays.

      Maps are a bit harder. The Apache team came up with a serialization for
      Java Hashtables last year which Paul also implements in SOAP::Lite. It's
      essentially a SOAP compound type which is a list of name->value pairs:

      <thing xsi:type="xmlsoap:Map" xmlns:xmlsoap="<namespace>">
      <name xsi:type="string">item 1</name>
      <value xsi:type="int">54</value>
      <value xsi:type="boolean">true</value>
      <name xsi:type="string">item 2</name>

      There was a bunch of discussion on soapbuilders about this back in April
      (search for "xmlsoap:map" or "map types" in the archives), which was never
      entirely resolved. Some folks felt that the above encoding is the cleanest
      way to represent a map type, and others felt that the following syntax was

      <thing xsi:type="SOAP-ENC:Array" SOAP-ENC:ArrayType="xmlsoap:Mapitem[2]">
      <name xsi:type="string">item 1</name>
      <value xsi:type="int">54</value>
      <value xsi:type="boolean">true</value>
      <name xsi:type="string">item 2</name>

      ...basically the same, but explicitly expressed as an Array of pairs.

      The folks on the array side of the argument held that such a serialization
      would be more palatable to a "raw" section 5 decoder than the
      Apache/SOAP::Lite one, therefore causing less interoperability problems.

      The folks on the other side put forth that a) needing to understand the
      "xmlsoap:Maptype" type in the above example is just as much an interop issue
      as the "xmlsoap:Map" type in the first example ... and b) a Map is not
      actually an Array (i.e. it doesn't have order, sparse Maps don't really make
      sense, etc).

      Check out the earlier discussion, and chime in. It's too bad (sorry, Simon
      :)) to open this can of worms up again, but I do think it's important that
      we have a shared map type. Let's figure this out.


      ----- Original Message -----
      From: "Rosimildo daSIlva" <rosimildo@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Monday, July 02, 2001 5:25 PM
      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

        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.