OK - calmer / wiser today ;)

"Many of the use cases were fantasy - something vendors where / are hoping to sell in the SOA orgy." examples? Im curious.

Correct to call me - that's gut feeling. What I'm getting at there is I feel many of these evolved as a result of people working on SOAP / WS-* forseeing problems / use cases which no one was already facing / doing in the real world i.e. there was no experience to be applied, lessons learnt in defining the specs. That's in contrast to REST / HTTP.

"So what's the addressing scheme for? And how did we get to HTTP over SOAP?. Also document / literal style services aren't about calling remote APIs - what you describe is only a subset of SOAP - Encoded / RPC over HTTP." The endpoint url? It's not required. An engine will ask you for an endpoint, some place to deliver a message. I can route soap over smtp/e-mail and process it as an asynchronous queue. Document passing IS a form of rpc in that the receiving side looks at the message and decides what to do w/ it. the only difference between formal rpc and document passing, is in the nomenclature. In the end, you are sending a message, a message as a document or a message in a more common "function call like document" that warrants a response.

Was attempting to justify my view that SOAP is protocol in the sense HTTP is a protocol and that SOAP re-invents a bunch of things that already exist. I also see the origins of SOAP (and XML-RPC) as having been fundamentally driven as a mechanism to exploit firewalls - that only port 80 is open, but that's me.

All generalizations are wrong.

Very much agreed - but that defeats the point of ranting ;)

Once you know how, it's easy. Learn soap, learn soap toolkits, and basic soap debugging, and it becomes portable. Sorry, this "illusion" and "bullshit" (from earlier) is subjective.

Agreed again but the learning curve is a problem. I've long since taking SOAP seriously as something I need to follow closely but last time I did, reached the point of being able to hand-code WSDL (pretty much required if you're publishing web services in dynamic languages) and regard myself as generally able, if required.

My (few) first-hand experiences, doing company-to-company interfaces, suggest to me the average developer response to SOAP and web services is a preference to dealing purely in terms of APIs and a lack of interest in understanding what happens behind them (this thread could be a case in point as well). That translates into problem solving of the "it works / it doesn't work" kind - if there's, say, a failing HTTP proxy server between the two endpoints, locating the problem becomes very hard.

More to the point, if responsiblity for SOAP interfaces becomes the job of sysadmins, what are the chances of their being able to isolate problems when the interface "stops working"? For a point-to-point SOAP interface, the answer might be "perhaps" although I'd expect weekend calls to the developers, but if you've got async SOAP messages passing over a number of intemediate systems, identifying why a message failed to reach it's final destination is likely to be a mammoth effort (guessing - no anecdotes). By contrast, figuring out where an email got lost is do-able.