In many applications (mostly enterprise), the extra overhead is well worth it because of the time it saves the developers. With .NET for example, you simply add the tag "[webmethod]" before the declaration of your method, and it becomes available over the Web. And if you're building the client, you simply point your tool to the URL of the service, and it immediately pulls the declaration of all methods along with their documentation if available, and also provides autocomplete and compile time validation on those remote methods. So, most developers don't even know about SOAP and never see a SOAP message. It's all done behind the scenes. If you're using a tool that doesn't have good support for it, though, then you're going to have a hard time with it.
wget http://weather.com/api?field=temperature&zip=02142
and get back a file consisting of "52" or something similarly simple.
Currently I have to get a 1k+ file and create a parser for it. I can't even find a really simple format that would allow me to use prebuilt XML parsers. If anyone knows of a dead simple API for temperature, precipitation, etc., I will upmod you at least once.
I don't think I've ever seen an instance of SOAP used appropriately, and I'm finding it hard to think of even a theoretical example where it would be a good idea. Maybe I'm not the target audience, but it seems to me the code, object size and data transmission overheads are almost never made up by any advantage SOAP offers. I think I'd consider ASN.1's XML encoding before I ever considered sending a SOAP message somewhere. At least then you could translate it to DER for efficiency.
i do, however, agree that for most people, SOAP and RPC style services are pretty much synonymous.
Most of the haters on SOAP and other thick WS technologies are people trying to do simple AJAX type message transfers. SOAP is a little heavy for that. But when you try passing messages between multiple systems in multiple languages, it becomes the obvious solution. As far as the following response goes... "allow me to put it this way: 1k of text to get a 2 or 3 digit temperature from a weather service." SOAP stacks will automatically parse that 2-3 digit number into the correct data type for the platform/language you are using. Now say instead of a 2-3 digit number you passed an entire object or data structure. Would it be easier to role your own parser or have the SOAP stack automatically marshal it for you?
Added to this, when you use the full set of SOAP technologies including WSDL and XSD, you also have data validation and to some extent, documentation. This is what JSON and the likes lack. If you provide a WSDL I can look at it and usually use a tool to automatically generate all the data types and interfaces needed (ie. wsdl in .Net). You point me at a JSON interface and I have no such luxury. I wont know what data to expect until you write documentation for it. Further neither of us would know if each others messages were valid without some kind of custom validator.
Also SOAP is transport layer agnostic. If you use HTTP you can take advantage of any compression the underlying platform supports. Apache's Axis and Perl's SOAP::Lite both support HTTP compression in their SOAP stacks. I am aware of ways to enable it in .Net as well.
Advances in computing power and network resources are making SOAP a more viable option, not less. It comes down to using the right tool for the job and REST is viable in some applications, but SOAP is as well. SOAP's life span will be at least as long as COM or CORBA. They haven't completely died yet either...
JSON stacks not only do that, but they do it better because the set of available data structures in JSON is constrained to a sensible subset - you don't end up having to replicate complex classes in multiple different languages just to get a chunk of data from one place to another.
Has anyone in the history of computing ever really taken advantage of the "transport layer agnostic" aspect of SOAP?
To my knowledge, there is no "built-in" way to specify if a number should be parsed as an int or a float in JSON. The idea that one of JSON's strengths is it "is constrained to a sensible subset" is a naive view. Yes it is a strength if you are only using dynamic languages, which is valid given the nature of most of the projects talked about on YC. However, enterprise projects are usually loaded with formal specifications, UML diagrams, and usually use languages with static typing. A mixture perfect for SOAP.
"you don't end up having to replicate complex classes in multiple different languages"
SOAP and almost every SOAP stack have been designed to prevent this. Almost every SOAP stack has a tool with naming similar to wsdl2java, wsdl2perl, etc.,. Again, narrowly looking at SOAP without understanding the associated technologies, mostly WSDL and XSD, the technology as a whole cannot be effectively evaluated. I don't expect any of the Web 2.0 AJAX guys to understand the benefits of an implementation with such a formalized specification or broad scope. However, SOAP was created to fit the needs of large enterprises trying to interop with other large enterprises. It covers a huge scope and various edge cases. JSON covers a very narrow scope. The original post talked of SOAP as a dead technology. It isn't. Is it the best for AJAX style web services? Maybe not. Don't simply disregard it as a viable solution in all cases though.
Yes, people use the transport layer agnostic aspect of SOAP. The first SOAP service I implemented used SMTP. It worked very well for sending messages to offline clients. SMTP provided queuing and storage of messages until a client came online and requested it.
At my current enterprise gig, SOAP messages are passed via MQ. This provides for additional facilities (transactions, message persistance) that SOAP in itself does not offer.
Note that there's been a fair bit of resistance to Axis2, with a lot of people preferring to stay on 1. I believe they changed the entire team from 1 to 2.
The claim of early SOAP advocates was that it would enable more loosely coupled, 'be liberal what you accept and conservative about what you generate' type services, especially when compared to older technologies like CORBA.
Unfortunately, the approach taken to this was to add more and more metadata, and the outcome has been, well, lousy interop because implementations disagree over the metadata. The standards and the stacks have been designed and tested based on hypothetical use cases rather than having arisen out of real world uses and I think we all know how well that approach works out.
It actually turns out that there are some things that SOAP is good for - for example, you want to create a service that can only be called with digitally signed, timestamped requests from known clients you trust, well, you can do that with SOAP pretty easily compared to rolling your own. But unless you are doing B2B, it's unlikely you have any need to do that - and even if you did you will probably find yourself mandating a particular stack for both client and server to make it work. So much for loose coupling - SOAP ironically turns out to be great for tightly coupled SOA.
http://www.prescod.net/rest/
http://www.prescod.net/rest/rest_vs_soap_overview/
That said, magical RPC-injection protocols like SOAP often work really well for quick and dirty apps within a single organization.
The platform independence is huge for obvious reasons. The XML based querying is huge because now the data model is totally hidden from our users. We just work from what they're asking for.
However, provided your server can talk to it at all, Microsoft's toolchain works really, really well for anybody writing a client. If you are providing a web service and want .NET developers to be interested, you owe it to yourself and them to provide a SOAP interface.
I don't have a link, but I remember hearing Jeff Barr from Amazon Web Services claim that the services they provided in both REST and SOAP saw an order of magnitude traffic to the REST interface.