
Simplicity and Utility, Or, Why SOAP Lost (2014) - bb88
http://keithba.net/simplicity-and-utility-or-why-soap-lost
======
eesmith
We could never get our SOAP systems to interoperate. In one case, we had a
Java server, that the Python SOAP library were were using couldn't understand,
so we ended up interposing a Perl program that could handle the Java SOAP
output and convert it to something Python could follow.

In another case, the server (running on Windows, don't know the implementation
language) returned a DIME message (Direct Internet Message Encapsulation; see
[https://msdn.microsoft.com/en-
us/library/aa480488.aspx](https://msdn.microsoft.com/en-
us/library/aa480488.aspx) ) for one of the API calls. Why? Because it attached
a "binary" file ... which happened to be a text-based document that could
easily have been XML-escaped and included in a SOAP response.

This might be fine if both sides of communication were using an enterprise-y
SOAP library from MS or IBM that implemented all the bells-and-whistles, but
we were using Python, and the SOAP packages for Python didn't understand DIME.

DIME wasn't a hard system to support, so we ended up writing our own parser
for it. Still, it was annoying.

This lack of real interoperability left a bad taste in our mouth for using
SOAP in a heterogeneous environment with many different SOAP libraries.

