SOAP was engineered by enterprise companies for enterprise applications. It came form the same thought train as COM/DCOM, CORBA, etc.,. It is still a major player in the enterprise world. You wont see many B2B apps that don't use SOAP or some other XML payload. I have used SOAP extensively in PHP and C#, together even. The support is there for it if you look. Java actually has good support for SOAP, if not the best (http://java.sun.com/webservices/http://ws.apache.org/axis/).
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...
"SOAP stacks will automatically parse that 2-3 digit number into the correct data type for the platform/language you are using."
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?
"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"
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.
"Has anyone in the history of computing ever really taken advantage of the "transport layer agnostic" aspect of SOAP?"
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.
we do a lot of stuff with soap over queues (msmq in our case, but same difference) as well. as i've been interviewing people, i've observed that stuff like this is really rare, so not many people have actually stopped to think about what you could do with something like WS-Addressing and a queue based bus.
however, i totally agree with most of the rational critiques of the WS-* stack - it's gotten way too complicated and in my view simplicity has been sacrificed at the altar of XML Schema.
Comments
SOAP was engineered by enterprise companies for enterprise applications. It came form the same thought train as COM/DCOM, CORBA, etc.,. It is still a major player in the enterprise world. You wont see many B2B apps that don't use SOAP or some other XML payload. I have used SOAP extensively in PHP and C#, together even. The support is there for it if you look. Java actually has good support for SOAP, if not the best (http://java.sun.com/webservices/ http://ws.apache.org/axis/).
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...
"SOAP stacks will automatically parse that 2-3 digit number into the correct data type for the platform/language you are using."
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?
"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"
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.
"Has anyone in the history of computing ever really taken advantage of the "transport layer agnostic" aspect of SOAP?"
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.
we do a lot of stuff with soap over queues (msmq in our case, but same difference) as well. as i've been interviewing people, i've observed that stuff like this is really rare, so not many people have actually stopped to think about what you could do with something like WS-Addressing and a queue based bus.
however, i totally agree with most of the rational critiques of the WS-* stack - it's gotten way too complicated and in my view simplicity has been sacrificed at the altar of XML Schema.