Born: Simple Object Access Protocol
Bullshit. Well, I believe at least the SOAP group surrendered the meaning of the protocol at some point and now, like many bastardized acronyms that pass through the evolution of their use, it no longer means anything. SOAP is a "brand" of messaging, with no implied simplicity.
SOAP to me means Sufficiently Obfuscated Access Protocol. No SOAP standard can exist without beginning as an obfuscated unreadable mess that must be constructed via binary API (usually generated from Sufficiently Obfuscated WSDL), or evolving into it once the application vendors whet their whistles on the standards boards and produce OFFICIAL STANDARD 2.0.
SOAP 2.0 seems to be a lot of the problem, where they took a heapload of things that belong in the transport layer (and were naturally in the HTTP protocol features) and placed them in the message itself. Security. Actions. Signing.
That's called message pollution. Let's use good old snail mail as an example. When I send a letter to someone (wow, it's been a while), I don't put the destination address, source address, cost of postage, etc on the actual letter.
I just write what I want to say to the person.
THEN, on the envelope, goes the destination address, source address, postage, priority delivery information, etc etc etc.
At my latest corporate job, they are obsessed with the "canonical model" of webservices, aka the grand unified web service (does this ever work in corporations? this deserves expounding) which a single message format for every single webservice in the company can be called with and be fit into.
Which results in an xml message like this:
namespace1:a
namespace2:long
namespace3:deep
namespace4:tree
namespace5:of
namespace6:tags
before you even get to the tags/message you care about
closing tags are left as an exercise to the reader...
usually with crap like "Payload" "Transport" "Server" and other crappy names that add nothing to the semantic content of the message. Just awful.
Huge number of long ugly namespace decls.
Of course tons more long ugly soap headers.
Oh. The WSDLs.
In SOAP land, of course, nobody in their right mind composes messages by hand to other systems. Everyone uses APIs to generate the text that is sent to the far-flung land. Either those libraries are provided or generated used black magic frameworks based on WSDLs, with all the attendant issues with code generation strategies (aka everything's fine, unless you need to deviate ...just ...a ...bit in validation or error handling or formatting).
The basic basic basic idea of web services was to sacrifice the advantage in speed, size, and overhead of binary protocols in order to provide a text-based human readable format that would be inherently easier to read, understand, debug, develop, store/archive/monitor, agree on standards, validate/verify, etc.
The cost was the overhead of text in parsing, size, bandwidth costs, etc.
Well, thanks SOAP, because every SOAP API I have seen destroys almost all of the intended advantages of using text and the medium, and then plops on all the problems of binary protocols in the process of producing the binary libraries that produce the text messages.
The worst of all worlds.
As of now, it's been a solid decade, and the vendors have dug in their heels on SOAP. God do they make money on that stuff. Hardware vendors make money on bigger machines. Well, IT departments get to convolute things and entrench themselves.
And boy howdy do they convolute things. That "canonical model" grand unified messaging?
- Adds another layer to any service deployment as your local service needs to be integrated into the "canonical model" which delays things.
- Adds another department and hardware for the software that intermediates the canonical requests to a centralized service endpoint into the simpler endpoints on the backend that actually do the work. Add another layer or three, that's the enterprise way.
- Adds processing overhead delays due to the additional message translations in the actual calls, and of course more servers to be improperly load balanced and fail.
- Hey, do you want to have your functionality release schedules be dependent on other people's release schedules that have NOTHING to do with you? Good news, the grand unified canonical model is here to make sure that everyone is dependent on everyone else, and you will have service outages for new functionality updates in other people's services that have NOTHING to do with you.
Oh, but enterprise people like strangeholds, miniature dictatorships that they can rule over, make their budgets unquestionable, and, oh, did our webservice mess up your website and business is screaming at you over our fuckup? Well, I have a monopoly on internal webservice transport that is unassailable, so I'll just say too bad and here's some earplugs.
