4 ms·

I don't know what wsdl's you were dealing with, but I met a fair amount of them who were not consumable by neither php-soap, python and even a java client while

by route66 16y ago

I don't know what wsdl's you were dealing with, but I met a fair amount of them who were not consumable by neither php-soap, python and even a java client while trying to read a .net one. The reason people are writing their own envelopes in cases (like I did also) is because the tooling is not delivering up to it's promises. (Let alone that the server might not even understand the two-line-code genertated nusoap reponse because he interpretes some ws-* rules about namespaces differently. The conclusion is: nobody wants to write his/her own envelopes.

kaylarose 16y ago
Every time I here about regular Soap clients failing, it's always in regard to trying to consume a .NET service. I don't know anything about .NET, but I wonder if there is something profoundly different that is going on behind the scenes, or does it just generate crufty WSDLs? Can anyone shine more light on this?
- route66 16y ago
  My problems were in fact with Java web services. There are different interpretations possible of the recent SOAP standards (or non-standards, as some are more de-facto than ratified) of smaal details as where to put type-info in the wsdl and if it is allowed to be redundant. This way sensible tooling is defied. Serving and consuming smaller services with light messages and shallow structure works mostly out of the box. The going gets rough when people put half their strongly typed domain logic in the wsdl which has to be recereated on the other side. Hint: Collections != Arrays != Hashes So, problaby not .NET but bloat related. Interoperability is a problem on all sides though.
- RickRoll 16y ago
  Microsoft was the only one to imlement the standarts completely in .NET 3.5 (WCF). Because all others were slow, in .NET 4.0 some advanced WS-* features are not used and interop with IBM/Oracle tools is almost perfect.

by route66 16y ago

kaylarose 16y ago

Every time I here about regular Soap clients failing, it's always in regard to trying to consume a .NET service. I don't know anything about .NET, but I wonder if there is something profoundly different that is going on behind the scenes, or does it just generate crufty WSDLs? Can anyone shine more light on this?

route66 16y ago
My problems were in fact with Java web services. There are different interpretations possible of the recent SOAP standards (or non-standards, as some are more de-facto than ratified) of smaal details as where to put type-info in the wsdl and if it is allowed to be redundant. This way sensible tooling is defied. Serving and consuming smaller services with light messages and shallow structure works mostly out of the box. The going gets rough when people put half their strongly typed domain logic in the wsdl which has to be recereated on the other side. Hint: Collections != Arrays != Hashes So, problaby not .NET but bloat related. Interoperability is a problem on all sides though.
RickRoll 16y ago
Microsoft was the only one to imlement the standarts completely in .NET 3.5 (WCF). Because all others were slow, in .NET 4.0 some advanced WS-* features are not used and interop with IBM/Oracle tools is almost perfect.