Perfect Integration 12 - the dont's

I changed my mind and decided to end this series with positive do's, so this is the dont's one. Then again reserving no. 13 for the dont's was a superstitious move anyway, and as I'm neither religious nor superstitious (they usually travel in pairs), it's better this way

This post is about debunking TLA's and FLA's. XML, SOAP and REST primarily, but Webservices and other concepts whose added value is flimsy or even absent, will get proper attention

XML is a syntax, making it part of the Integration messaging theme.

Back in 2000, when I started to say that XML doesn't add anything to Enterprise business application integration other than overhead, complexity and confusion, the most-heard pro of XML was "it's the language of the future"
I always responded with "I can't do business with the future, can I?" and explained how 1,000 years ago we Europeans (economically, politically) all spoke Latin in Europe, followed by French in 1700's, and English in 1900's, without anything ever changing to (economical, political) business itself as a result.
Was there a businesscase for speaking the new language? At some point, when a growing minority started to speak it, yes. Has this ever been the case with XML? No, never. And it never will:
Google never used XML, didn't even think about it. Twitter deprecated XML use in 2010, and Facebook is doing so now. Google moved to a proprietary format, Twitter and Facebook "will go flat-file": JSON

Don't use XML for Integration. It is nice for humans to read, but in the machine-to-machine integration world, it has failed to prove its value in the last 10 years - because there is no value

SOAP can't be placed in any of the Integration themes (messaging, transportation, transformation). It tocuhes some aspects of The Envelope

SOAP was originally started in 1998 by Microsoft as an attempt to do what it says: Simple Object Access Protocol. W3C adopted it to describe exchanging structured and typed information between peers in a decentralized, distributed environment.
It is an exchange mechanism, but relies exclusively on a fixed message format (XML) and a fixed transportation protocol (HTTP). Its main focus is on the SOAP envelope, yet doesn't describe that at all: the only mandatory thing in there is the word Envelope itself.
Everything SOAP tries to implement has already been taken care of by SMTP, the transport protocol used for email, in a far better, standardised and successful way.
SOAP will cause you to reinvent the wheel and describe your own envelope, yet tie you down with highly interpretable mandatory or optional elements. Will it audit or certify your SOAP inventions? No. So what's the use?

Don't use SOAP for Integration. It restricts you to one message syntax, one transportation protocol, and leaves it up to you to reinvent your own SOAP thing. It has failed to prove its value in the last 10 years - because there is no value

Web services can't be placed in any of the Integration themes (messaging, transportation, transformation). Like SOAP, they focus on a very fixed tech solution for unknown business problems

W3C defines a Web service as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards".
What's the goal? The point? What are the alternatives? Why is this the best solution?
Every single format can be processed by machines, if -and only if- it can be understood and agreed upon by humans doing business. W3C doesn't know anything about doing business, and XML, SOAP, WSDL, UDDI and Web Services all were invented by them

Don't use Web services for Integration. They restrict you to one message syntax, one transportation protocol, one way of writing down your web service, and leave it up to you to reinvent your own web service. It has failed to prove its value in the last 9 years - because there is no value

I have struggled to write this down, as a post with a subject like this basically only destroys. There is one big positive thing to mention: all these concepts were invented by W3C. Tim Berners-Lee heads that organisation, who accidentally invented the Internet - so that's why people put value onto W3C concepts

What these acronyms all have in common, is inventing their own way of laying down the exact structure of How things should be said - without taking into consideration What can be said