3 ms·

> that SOAP pain The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specific

> that SOAP pain The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works. After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you wanted to consume something from Biztalk, PeopleSoft, any Oracle Product, or any other Enterprise product you could just add a service reference to a WSDL URI and a tool would generate your interface classes and DTO classes for you in your language of choice. In the Open Source world things were very different. Whenever I would provide a service to be consumed by a vendor, I would provide reference implementations in C#, JAVA, Python, and PHP. I would spend about 15mins on C# and JAVA, then the rest of the day fiddling with Python and to a lesser extent PHP. PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. Around 2012 I remember working with a partner company that was using RAILS for their platform. It was an absolute nightmare for them to integrate with our existing SOAP service layer. SOAP protocol libraries were the least of their issues. No client certificate authentication in their HTTP libraries. No serious XML support. They wrote their own implementation from scratch.

bvrmn 9y ago
> I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. Python has decent SOAP server implementation with one-to-one request/response schema modeling https://github.com/baverman/dropthesoap https://github.com/baverman/dropthesoap
oneplane 9y ago
Well, that's actually where the SOAP pain is: it used to be that you couldn't make any good use of it unless you were using walled-garden vendor software. A lot of people dislike Windows, Visual Studio and anything else made by Microsoft. Same goes for Oracle. So then you are left with everything else, which basically means: everything without SOAP, Enterprise editions of runtimes, service buses and the likes. There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work. While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).
karmajunkie 9y ago
> when implemented properly you forget it's there because it just works. I think that's the link missing for most developers. SOAP was intended to allow machine-generated SDKs to remove all of the sharp edges of dealing with it, and in that regard it was largely successful. What brought it down was the advent of non-"enterprise" web development—development happening outside of a .Net or Java IDE that generated code for you. If you ever had to handroll a wrapper for a SOAP endpoint though, god help you. I honestly believe SOAP was the thing that made XML seem uncool by comparison to JSON and REST. JSON still doesn't solve data representation problems as well as XML, we've just learned to accept "good enough" in its stead.
collinmanderson 9y ago
> PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. I've tried suds and zeep. They both didn't really work in my specific cases. My strategy from now on is to write a bit of code in Visual C#, then analyze the xml traffic, and then generate that same XML using Python/PHP. The SOAP protocol is actually pretty simple once you know how it works. SOAP has a lot of problems, but it's pretty amazing that you don't need a client side library to use it in Visual C#.

bvrmn 9y ago

> I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. Python has decent SOAP server implementation with one-to-one request/response schema modeling https://github.com/baverman/dropthesoap https://github.com/baverman/dropthesoap

oneplane 9y ago

Well, that's actually where the SOAP pain is: it used to be that you couldn't make any good use of it unless you were using walled-garden vendor software. A lot of people dislike Windows, Visual Studio and anything else made by Microsoft. Same goes for Oracle. So then you are left with everything else, which basically means: everything without SOAP, Enterprise editions of runtimes, service buses and the likes. There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work. While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).

karmajunkie 9y ago

> when implemented properly you forget it's there because it just works. I think that's the link missing for most developers. SOAP was intended to allow machine-generated SDKs to remove all of the sharp edges of dealing with it, and in that regard it was largely successful. What brought it down was the advent of non-"enterprise" web development—development happening outside of a .Net or Java IDE that generated code for you. If you ever had to handroll a wrapper for a SOAP endpoint though, god help you. I honestly believe SOAP was the thing that made XML seem uncool by comparison to JSON and REST. JSON still doesn't solve data representation problems as well as XML, we've just learned to accept "good enough" in its stead.

collinmanderson 9y ago

> PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. I've tried suds and zeep. They both didn't really work in my specific cases. My strategy from now on is to write a bit of code in Visual C#, then analyze the xml traffic, and then generate that same XML using Python/PHP. The SOAP protocol is actually pretty simple once you know how it works. SOAP has a lot of problems, but it's pretty amazing that you don't need a client side library to use it in Visual C#.