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.
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.
(Cross-posted @ Business or Pleasure? - why not both)