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

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

Expand Messages
  • Bob Cunnings
    Hello, Some thoughts... If interoperablility is defined as the ability to send and receive SOAP envelopes correctly, is there any need to impose a requirement
    Message 1 of 80 , Jul 2, 2001
    • 0 Attachment
      Hello,

      Some thoughts...

      If interoperablility is defined as the ability to send and receive SOAP
      envelopes correctly,
      is there any need to impose a requirement for transformations (e.g.
      addition, string reversal) merely
      to prove that no one is "cheating"? Especially if it requires the definition
      and implementation of new interfaces?

      "Raising the bar" might be accomplished in several areas:

      -- Section 5 encoding (additional types, more complex serializations)
      -- Section 4 processing requirements (header processing, the
      "mustUnderstand" attribute, fault message)
      -- Section 2 message exchange model (intermediary behavior)
      -- Beyond Section 5... specifically "document literal" messaging.

      So where to expend further effort?

      Although the XSD built-in types could be covered exhaustively, is it
      worthwhile? Certainly a few more could be
      added to the "echoXXX" methods to round things out, but maybe we're at a
      point of diminishing returns there. The
      "Group B" methods were meant to test a few more complex RPC messages, namely
      multiple in params, multiple out
      params, and multi-d arrays... but if the goal is to test within the confines
      of Section 5, is there a need to go much further?
      Like data structures beyond those addressed in Section 5?

      Given that, would time and energy be better spent moving on to one of the
      other "interop" areas?
      Header processing, and Section 4 compliance in general come to mind
      immediately. These matters are important and transcend
      the encoding issues. Header entries may well be almost universally used in
      deployed web services, and I think that
      there is a certain urgency to be felt... already many SOAP extension
      proposals are on the table, requiring the use of
      header entries (SOAP Routing Protocol comes to mind). The draft header
      processing testing proposal is at:
      http://www.whitemesa.com/interop/proposalC.html

      I'll update the "base" proposal to include decimal and boolean types, are
      there any other XSD built-in types
      for which there is a case? Should we do them all and get it over with?

      Comments, please!

      RC


      > I'm all for it, I would however like to keep each set of tests separate,
      > perhaps we should come up with a different naming schema, there's no
      reason
      > that you have to tackle the current round B tests before the round C
      tests,
      > or the new additional types testing. I'd rather write 3 sets of smallish
      > servers/clients than one big chunk of server/client code.
      >
      > Cheers
      > Simon
      > www.pocketsoap.com
      >
      > -----Original Message-----
      > From: Sam Ruby [mailto:rubys@...]
      > Sent: Monday, July 02, 2001 1:40 PM
      > To: soapbuilders@yahoogroups.com
      > Subject: Re: [soapbuilders] Re: Where's decimal?
      >
      >
      > Paul Kulchenko wrote:
      > >
      > > I think it's not enough.
      >
      > No question there. However, that doesn't mean that there isn't value..
      I'm
      > still seeing endpoints that don't support the SOAPAction specified in the
      > whitemesa WSDL, or respond with rather unexpected (to me, at least)
      formats
      > for simple formats such as dates.
      >
      > > We can keep echo* tests and add similar group of add* tests, which
      > > will add fixed string/number for simple types and, for example,
      > > duplicate last element of array for add*array tests.
      >
      > Rich Salz wrote:
      >
      > > Not that any of us are cheating, of course, but raising the bar like
      > > this is a good idea.
      >
      > For those who played honestly the first go around, I doubt this will
      > surface additional incompatibilities. You are more likely to find
      > incompatibilities around the edges, with things like -INF, or nil values
      > passed as floats, or arrays of length zero. Paul, I know that you have
      run
      > tests like these before...
      >
      > In any case, I am in full agreement that Round 2 as currently stated does
      > not raise the bar far enough. Personally, I see no reason to defer the
      > simple things that we are describing to a stage three... I mean, what
      > servers should not be able to handle boolean? Addition?
      >
      > - Sam Ruby
      >
      > P.S. This go around, I'm planning to have Apache participate in a first
      > class way... public server, posted client interop results, etc.
      >
      >
      > -----------------------------------------------------------------
      > 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.