RE: [soapbuilders] another question re: maps, etc.
- hi guys,
since sam, dug and others all work for IBM on
the same software, i'd like to know which mapping
IBM intends to implement for Map.
right now, apache seems to use <sequence>.
but now sam is saying he prefers <all>, and
he's involved in the axis project that will
could the guys in the ibm camp let us know
what they intend to do, because i would prefer
not to keep changing the built-in GLUE mapping
depending on the last email from an ibm developer ;-)
From: Sam Ruby [mailto:rubys@...]
Sent: Tuesday, July 03, 2001 4:10 PM
Subject: RE: [soapbuilders] another question re: maps, etc.
Martin Gudgin wrote:
> I think Sam meant 'all' rather than 'any'. My view is that you should
> use 'all' when order is semantically significant ( that is if, in thiscase,
> key before value means something different from value before key ). Iforder
> is not semantically significant then pick one and used 'sequence'Yes, I meant 'all'. Sorry.
However, my read of the specs seems 180 off of yours. From what I see,
'all' means that the order is not significant, and 'sequence' means the
My preference is that the order NOT be significant.
- Sam Ruby
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:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
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,