protocols with simple (or lightweight) in their name usually are anything but.

Not a coincidence. Simple to implement != simple to explain to your boss (`it's standard industry practice'). The name is meant to sell the standard to non-techies.

SOAP is no more the acronym of Simple Object Access Protocol since version 1.2

That's no excuse (and if you read the article you'd know that it acknowledges this fact).

Agreed, When i started SOAP around 2000, it was very simple. After that we for more into the awful WSDL 1 (WSDL 2 is better). But the number of WS-* and the different implementations that are all incompatible is just a nightmare.

In 2001 I gave a talk (I believe at OSCon, to a packed audience) titled "Why SOAP Sucks". I started with a print-out of all the specs required to implement SOAP fully (there were lots of incomplete implementations around at the time, but barely any complete ones). It was more than two reams of paper (around 1100 pages of spec, if I recall). It had quite an "impact".

IIRC, the Table of Contents for the SOAP spec is bigger than the entire XML-RPC spec, yet SOAP offers little practical advantage. Luckily many new RPC implementations bypass both SOAP and XML-RPC and are looking to REST. $deity help all of us who need to work with legacy SOAP, however...

I can totally relate to these two articles, having recently attempted to write a .NET SOAP client for a web service that uses the (non-standard) SOAP with Attachments method for sending binary data. For something that was created to provide simple interoperability, SOAP is rife with a ridiculous number of inconsistencies and competing mini-(non)standards.