RE: [soapbuilders] .NET encoding stuff
- Graham Glass wrote:
>Perhaps we should focus on messaging (SOAP with attachments?) instead of
> Yann Christensen wrote:
> > Generally speaking, folks that look at SOAP fall into either the RPC
> > camp or the XML messaging camp.
> this makes me thing that maybe we should start concentrating
> on some kind of literal-encoding-interoperability rather than
> beating section 5 to death.
beating encoding to death.
Just curious, can somebody clue me in on how one does messaging with DotNet
- Sam Ruby
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
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
--- 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
> 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
> <remove name="HttpGet"/>
> <remove name="HttpPost"/>
> -----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:
> [SoapRpcServiceAttribute(RoutingStyle =
> and, at the method level:
> [SoapRpcMethodAttribute( "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,