4 ms·

You Are Doing It Wrong. Anybody that tries to interface with a SOAP interface by writing envelopes by hand is wasting their time and half-implementing the (lon

by pak 16y ago

You Are Doing It Wrong. Anybody that tries to interface with a SOAP interface by writing envelopes by hand is wasting their time and half-implementing the (long, terrible, complicated, blah blah) spec. Find a good toolkit. Yes, the protocol is way over engineered but good tools can and do abstract that all from you. For instance, PHP's standard library lets you plug in a WSDL URL and consume SOAP services in two lines of code. (And because it is a good toolkit, it lets you spit out all traffic with one debug flag, unlike whatever terrible thing the author of this article is using.) Most of what people complain about in these comments would be moot with good tools. You would probably complain about REST if you didn't have curl or Firebug and had to telnet all your test calls--that's equivalent to what most people here seem to be doing.

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.
nailer 16y ago
Thanks for your info. I've tried (in the last few hours) to find a good toolkit to consume WSDL rather than write my own envelopes as you mention. I'm investigating 3 different WSDL->JS libraries. * Guru4 JavaSriptSOAPClient - Unmaintained since 2006 * Python wsdl2js - not widely tested or maintained * Apache CXF wsdl2js - maintained, but doesn't seem to like the WSDL provided by my service provider. Of the three, Apache CXF is the only one that looks promising, but fails to generate any JS. I'm trying to fix it, but I keep encountering more old-style web-services acronyms. All I want are so classes - maybe I'm doing something wrong, but I simply don't think it should be this hard. If you're interested, the WSDL issues are detailed further in http://stackoverflow.com/questions/4827467/understanding-apache-cxf-wsdl2js-operation-as-more-than-one-output-part http://stackoverflow.com/questions/4827467/understanding-apa... Edit: I've found a maintained version of the Guru4 implementation at http://javascriptsoapclient.codeplex.com http://javascriptsoapclient.codeplex.com that I'm going to try.
masklinn 16y ago
Autogen very often fails if the WSDL generator of your provider and the WSDL consumer/code generator are one and the same. Trying to generate code using a Java toolkit from an MS wsdl? 90% chances of failure. Same the other way around.
- dansingerman 16y ago
  This is one of the main reasons SOAP has been a catastrophic failure. A protocol for interoperability that is vendor-specific? That's an oxymoron.
RyanMcGreal 16y ago
> Find a good toolkit. I spent a few weeks trying to find a good toolkit for the big hairy nested ape of a WSDL I was trying to consume, and nothing could parse it properly and expose the methods in a sane manner. I ended up doing just what the OP did - hand-crafted the request payloads in soapUI and turned them into templates that I could execute programmatically. I really hate SOAP.
nailer 16y ago
>> soapUI is an application that will let you fiddle around until you get the calls right. > WSDL In the OPs defense, it should be pointed out that SOAPUI is a WSDL client.
drdaeman 16y ago
Three years ago I've had to interface with SOAP-based service. After trying various libraries for various languages - only to find out they don't support something (I actually remember lack of ad-hoc polymorphism, inability to understand the response format with some weird reference-like structures, and inability to emit some obscure Java datatypes whose names I forgot) - I've ended up with generating query XML template by hand and processing replies with quick-and-dirty PCRE-based parser. Sure, it's Wrong(tm), but I did it in a lunchtime and the code worked like a charm. Sure, if I'd write in Java (I ended up with Perl5, as - thanks to CPAN - it seemed the most suitable for the task), all this SOAP stuff would be as simple as several clicks in NetBeans or whatever-Java-people-are-using. But I didn't knew Java enough to write everything I needed, I didn't like idea of Java SOAP-to-SomethingRESTful proxy, and I was quite scared of FactoryFactoryFactoryInterfaceActorProducerFactoryFactorySingleton libraries to dive into Java (yes, I know not all Java is Enterprise Quality, but system I had to interface with was extremly enterprisey).

by pak 16y ago

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.

nailer 16y ago

Thanks for your info. I've tried (in the last few hours) to find a good toolkit to consume WSDL rather than write my own envelopes as you mention. I'm investigating 3 different WSDL->JS libraries. * Guru4 JavaSriptSOAPClient - Unmaintained since 2006 * Python wsdl2js - not widely tested or maintained * Apache CXF wsdl2js - maintained, but doesn't seem to like the WSDL provided by my service provider. Of the three, Apache CXF is the only one that looks promising, but fails to generate any JS. I'm trying to fix it, but I keep encountering more old-style web-services acronyms. All I want are so classes - maybe I'm doing something wrong, but I simply don't think it should be this hard. If you're interested, the WSDL issues are detailed further in http://stackoverflow.com/questions/4827467/understanding-apache-cxf-wsdl2js-operation-as-more-than-one-output-part http://stackoverflow.com/questions/4827467/understanding-apa... Edit: I've found a maintained version of the Guru4 implementation at http://javascriptsoapclient.codeplex.com http://javascriptsoapclient.codeplex.com that I'm going to try.

masklinn 16y ago

Autogen very often fails if the WSDL generator of your provider and the WSDL consumer/code generator are one and the same. Trying to generate code using a Java toolkit from an MS wsdl? 90% chances of failure. Same the other way around.

dansingerman 16y ago
This is one of the main reasons SOAP has been a catastrophic failure. A protocol for interoperability that is vendor-specific? That's an oxymoron.

RyanMcGreal 16y ago

> Find a good toolkit. I spent a few weeks trying to find a good toolkit for the big hairy nested ape of a WSDL I was trying to consume, and nothing could parse it properly and expose the methods in a sane manner. I ended up doing just what the OP did - hand-crafted the request payloads in soapUI and turned them into templates that I could execute programmatically. I really hate SOAP.

nailer 16y ago

>> soapUI is an application that will let you fiddle around until you get the calls right. > WSDL In the OPs defense, it should be pointed out that SOAPUI is a WSDL client.

drdaeman 16y ago

Three years ago I've had to interface with SOAP-based service. After trying various libraries for various languages - only to find out they don't support something (I actually remember lack of ad-hoc polymorphism, inability to understand the response format with some weird reference-like structures, and inability to emit some obscure Java datatypes whose names I forgot) - I've ended up with generating query XML template by hand and processing replies with quick-and-dirty PCRE-based parser. Sure, it's Wrong(tm), but I did it in a lunchtime and the code worked like a charm. Sure, if I'd write in Java (I ended up with Perl5, as - thanks to CPAN - it seemed the most suitable for the task), all this SOAP stuff would be as simple as several clicks in NetBeans or whatever-Java-people-are-using. But I didn't knew Java enough to write everything I needed, I didn't like idea of Java SOAP-to-SomethingRESTful proxy, and I was quite scared of FactoryFactoryFactoryInterfaceActorProducerFactoryFactorySingleton libraries to dive into Java (yes, I know not all Java is Enterprise Quality, but system I had to interface with was extremly enterprisey).