I think this is largely accurate, but one thing the article misses is that SOAP was never as interoperable as it was claimed to be. If you had a Microsoft client and a Microsoft server, things would work great, but as soon as you started mixing vendor implementations, you quickly ended up in configuration hell. For simple SOAP messaging you could usually get it to work with enough elbow grease, but for any of the WS-* protocols you might as well be doomed. I lost days, if not weeks, of work to failed interop of WS-Security across two different vendors (both Java, and both with the code under my control).
I spent several years integrating Java/Linux/Unix/Microsoft/etc and I never ceased to be amazed at how many companies/programmers thought it required different code to make them interoperable. I had very few issues with SOAP interaction between systems because they are just text files.
For all intents and purposes, SOAP is a formatted pipe connection. The only issues I ever ran into were related to things like Java incorrectly implementing RSA encryption or Microsoft adding so much complexity that nobody used (and did not require).
There are still several major banks/insurance companies out there whose payroll transaction systems run on the SOAP implementations I put in place 10 or more years ago.
Now I see people claiming REST is better (and in many ways, they are correct), but I also see that large numbers of programmers don't really grasp REST any better than they did SOAP.
> I had very few issues with SOAP interaction between systems because they are just text files.
Did you write parsers for the messages by hand every time?
I did a bit of work with SOAP, and found interoperability to be a problem. Encapsulation and signatures both spring to mind. But then, i was using tooling on both sides. I shudder to think what dealing with SOAP messages manually would have been like.
Why would I write manual parsing code every time? There already are/were XML parsers in every language I needed to integrate. SOAP is just XML. XML is easy. I've moved to REST implementations but I have just quite got why anyone thought SOAP itself was anything complicated.
Microsoft's 'WS' implementations were a mess of SOAP, but that's a whole different story.
WCF is a mess and poorly documented. I have several significant implementations of WCF I support now and I really often wonder WTF Microsoft was thinking.
I once spent a day or two looking at WCF in Reflector. Interestingly, while the API makes it look like a tiered, flexible architecture it is not. Instead, at the bottom (!) layer you basically have case distinctions, depending on the layers that were configured on top.
Oh god, I have to deal with a SOAP service from a perl client...try dumping out a SOAP::Lite data structure once, and you will be wondering what in gods name the SOAP::NotLite one would have to look like.
