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