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'd like to know too. There are a lot of people here rubbishing SOAP without explaining why. I've consumed, simultaneously with hundreds of other developers from disparate teams, 100s of SOAP services across a number of financial institutions and any issues I ran into had nothing to do with SOAP. Generating code with SvcUtil is great and does what it's supposed to - and nothing stops you from refining it or writing your own service clients.

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.

SOAP is fragile, bloated and slow. It goes against what the very essence of a service should be, i.e. to expose functionality in as accessible and inter-operable way as possible. The higher up the WS-* stack you go, the less supported it becomes - eventually only the Big Enterprise frameworks from MS and IBM support the complete WS-* stack.

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

I touch on REST vs SOAP and why SOAP sucks here: http://www.servicestack.net/mythz_blog/?p=154

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...

It's a mediocre and bloated implementation of an idea that's neither particularly good or bad, but really old: remote procedure calls.

when i had to work with it the problem was incompatible implementations and extensions. i assume it would work fine with MS server and client, or with Sun (back then) server and client, but when you mixed them and tried to do anything even vaguely unusual, it hurt.

I've had my .NET clients talk successfully to .NET back-ends, Java back-ends, and Cobol wrappers with no problems, with security extensions, etc. all enabled. But the key to that was having an active architecture group responsible for ensuring consistency across the organisation (libraries for each client platform host).

The idea is fine. I'd cite thrift as essentially an implementation of the same thing, minus all the junk.

Yes I had to go back and check the date to make sure it was not 2005, because that was when we had this argument.

This project attempts a middle ground between SOAP and "roll your own"

http://barrister.bitmechanic.com/

It's JSON-RPC with an IDL grammar.