4 ms·

Why did SOAP win, and XMLRPC not win?

by bediger 16y ago

dochtman 16y ago
Big companies and their commercial interests.
- bediger 16y ago
  Why in an earlier age, did DCE fail so miserably? It was amply backed by ginormous corporate interests.
  - duncanj 16y ago
    One reason is that Microsoft's implementation was compatible enough with Sun's to pass tests but not to perform much useful work. Without MS's active participation, most enterprises wouldn't benefit from interoperability.
wiredfool 16y ago
Soap was supposed to be the enterprisey safe superset of XML-RPC. From my experience back at the beginning -- XML-RPC was slightly underspecified, and would have used a bit more of a firm hand about clarification of what was legal and what wasn't. SOAP was wildly overspecified and complexified to the point that you needed an army of consultants. Which is just perfect for enterprisey stuff, since you conviently have an army of consultants that need to have something to do. IMHO, XMLRPC inhabited a middle ground that was washed away by REST and ajax/json type interfaces. It's an extra bit of complexity that's just not all that popular now, rather than a stunningly less complicated version of SOAP.
- spolsky 16y ago
  Yep... as I remember it, XML RPC was "specified" by Dave Winer, and it was really sloppy. As I remember, there was no discussion of character encoding in the spec, and if you read the spec literally, you actually HAD to generate invalid XML documents because the spec was written by someone who did not understand that there was such a thing as character encoding and that it was important. And Winer absolutely refused to add features or to allow any kind of process by which XML-RPC could evolve into something good enough to use. Then the Microsoft people who brought you COM in all its baroque loveliness got their hands on the concept and made an industrial strength, godforsaken, complex thing called SOAP. The problem with SOAP mostly stemmed from the fact that they thought that all the work would be done by compilers and IDEs and so forth... they thought all the programmer would do is click a button and hey presto they would be able to run one object on one server and another object on a second server, and who cares what happens on the wire protocol? It's the compiler's job! But that's a terrible recipe for interoperability.
AaronWormus 16y ago
Microsoft was behind SOAP and quickly added it to Visual Studio.
vilya 16y ago
The two big differences, IIRC, were that XML-RPC didn't support authentication or any kind of structured types while SOAP did. Those were things that people at the time thought they needed.

Why did SOAP win, and XMLRPC not win?

by bediger 16y ago

Why did SOAP win, and XMLRPC not win?

dochtman 16y ago

Big companies and their commercial interests.

bediger 16y ago
Why in an earlier age, did DCE fail so miserably? It was amply backed by ginormous corporate interests.
- duncanj 16y ago
  One reason is that Microsoft's implementation was compatible enough with Sun's to pass tests but not to perform much useful work. Without MS's active participation, most enterprises wouldn't benefit from interoperability.

wiredfool 16y ago

Soap was supposed to be the enterprisey safe superset of XML-RPC. From my experience back at the beginning -- XML-RPC was slightly underspecified, and would have used a bit more of a firm hand about clarification of what was legal and what wasn't. SOAP was wildly overspecified and complexified to the point that you needed an army of consultants. Which is just perfect for enterprisey stuff, since you conviently have an army of consultants that need to have something to do. IMHO, XMLRPC inhabited a middle ground that was washed away by REST and ajax/json type interfaces. It's an extra bit of complexity that's just not all that popular now, rather than a stunningly less complicated version of SOAP.

spolsky 16y ago
Yep... as I remember it, XML RPC was "specified" by Dave Winer, and it was really sloppy. As I remember, there was no discussion of character encoding in the spec, and if you read the spec literally, you actually HAD to generate invalid XML documents because the spec was written by someone who did not understand that there was such a thing as character encoding and that it was important. And Winer absolutely refused to add features or to allow any kind of process by which XML-RPC could evolve into something good enough to use. Then the Microsoft people who brought you COM in all its baroque loveliness got their hands on the concept and made an industrial strength, godforsaken, complex thing called SOAP. The problem with SOAP mostly stemmed from the fact that they thought that all the work would be done by compilers and IDEs and so forth... they thought all the programmer would do is click a button and hey presto they would be able to run one object on one server and another object on a second server, and who cares what happens on the wire protocol? It's the compiler's job! But that's a terrible recipe for interoperability.

AaronWormus 16y ago

Microsoft was behind SOAP and quickly added it to Visual Studio.

vilya 16y ago

The two big differences, IIRC, were that XML-RPC didn't support authentication or any kind of structured types while SOAP did. Those were things that people at the time thought they needed.