Is there a consensus on why the SOAP/WSDL business sucks? Is it just a lousy bloated implementation of a potentially good idea or it's the whole idea that's misguided/unrealistic/foolish?
I don't need to run service calls from the command line - I have version controlled integration tests that I right click on and select "run", as should every major consumer of serious services.
I don't believe SOAP web services are always the way to go (I've never used any in my personal projects, preferring my own web API and/or a service bus), but that doesn't mean it's not suitable for other problems.
What's often missing from these debates is defining what environment you're operating in (legacy and dependant systems/platforms/interfaces, network architecture, how much architectural control you have, user load, number of developers, number of teams, release cycles, politics [what was the last big budget item that was purchased to solve the current problem], timelines etc.). Once you start identifying the environment details, some of the simplistic unqualified suggestions people make in these debates seem naive and ridiculous.
WSDLs promote code-gen and as different SOAP frameworks have varying levels of WSDL support, you often end up with broken + ugly code-gen when trying to consume from different SOAP stacks. SOAP is also a brittle format where even a small namespace change can break the entire request, this makes versioning (a core part of evolving services) extremely difficult.
I generally prefer clean HTTP APIs with Cool URI's and JSON which is a much faster, smaller, more versionable and tolerant format that provides a better programmatic fit than SOAP/XML: http://www.infoq.com/presentations/Heretical-Open-Source
In general I believe the topic of REST encourages elitist attitudes, cargo cults and un-pragmatic solutions, which I also touch on at: http://www.servicestack.net/mythz_blog/?p=665
and I still strongly believe message-based solutions promote better designs for SOA-style remote services: https://github.com/ServiceStack/ServiceStack/wiki/Advantages...