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

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

Expand Messages
  • Simon Fell
    aaaarrrrghhhhh !! :) a very good summary though. on a somewhat related note, i d be interested to hear what people think of this
    Message 1 of 80 , Jul 2, 2001
    • 0 Attachment
      aaaarrrrghhhhh !! :)

      a very good summary though.

      on a somewhat related note, i'd be interested to hear what people
      think of this
      http://discuss.develop.com/archives/wa.exe?A2=ind0107a&L=dotnet&F=&S=&P=19630

      Tim raises some interesting issues, but i'm not sure yet that i agree
      with him.

      Cheers
      Simon

      On Mon, 2 Jul 2001 18:24:35 -0400, in soap you wrote:

      >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>">
      > <item>
      > <name xsi:type="string">item 1</name>
      > <value xsi:type="int">54</value>
      > </item>
      > <item>
      > <value xsi:type="boolean">true</value>
      > <name xsi:type="string">item 2</name>
      > </item>
      ></thing>
      >
      >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
      >better:
      >
      ><thing xsi:type="SOAP-ENC:Array" SOAP-ENC:ArrayType="xmlsoap:Mapitem[2]">
      > <item>
      > <name xsi:type="string">item 1</name>
      > <value xsi:type="int">54</value>
      > </item>
      > <item>
      > <value xsi:type="boolean">true</value>
      > <name xsi:type="string">item 2</name>
      > </item>
      ></thing>
      >
      >...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.
      >
      >--Glen
      >
      >----- 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/
      >>
      >>
      >
      >
      >-----------------------------------------------------------------
      >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.