SOAP doesn't solve anything - a deep dive

In my last two blogs, I've talked about SOAP and its (lack of) contribution to IT in the last decade. I've also written about the basics of routing and enveloping

At last, I've touched upon the fundamental question: what if your envelope isn't equal to mine?

Well, as said before, the answer to that is simple: wrap it in your own envelope. Everyone does it.

Not only IRL with global mail procedures and systems, but queueing systems like Websphere MQ couldn't

End the SOAP: this is how simple it should be

After yesterday's scorn on the everlasting SOAP, another explanation about enveloping and routing is probably in place

In the ideal world, all service requests and responses are sent in an envelope, like in the old-fashioned mail. In the old-fashioned mail, however, we already see standards on a national level conflicting with those of another country, so even there is no uniform envelope-definition. But, as we've seen, they all have the same in common: a recipient, a sender, and a unique address in 4 stages: country; zip; street and number. In fact, the country indicates how the address is exactly made up, functioning as a "case statement" in IT

Well the design is complete. Now the big problem has to be tackled: what if your envelope isn't equal to

SOAP: the postman has already rung twice

SOAP. With the benefit of hindsight: the word was well-chosen, wasn't it?

Not even mature yet, it's already so overly complex and hard to understand -and still not complete enough, think of error handling- that it will die a silent death in the next years. Good riddance

We have SMTP for sending and receiving messages across the globe, what was wrong with that? It even relays messages, guarantees delivery or at least delivery notifications. It has a retry mechanism, it can send text and binaries and attachments, it can handle all kinds of encodings - need I go on?

What is it with reinventing the wheel that persists throughout IT? And why don't people just copy the things that work, when they want to copy an existing concept?

Guaranteeing guaranteed delivery: it's easy...

A man is sitting outside a bar at a table. He raises an eyebrow, the waiter nods back as a sign that he's seen him - the first part
When the waiter is ready, he comes over to his table. "Yes sir may I help you?. "One beer please", the man says. "Okay, be right back" - the second part
After a while the waiter comes back and puts the beer on the table. "Here you go sir". "Thank you" the man says - the third part
Yet a while later, the man winks the waiter again. "Be right with you sir" the waiter says. - the fourth part

About EDI and data quality

Missing data and lost messages are a natural phenomenon that occurs throughout each enterprise
Nothing to worry about really, as it's only human and so are applications themselves, as they're humanly-specced and -built after all

However, integrating applications like these causes a painfully clear visibility of these errors on the enterprise level, showing their significance as a whole:

Let's say that each application has an average fault percentage of 0.5%. When that application is connected to another one, it will thus foobar 0.5% of the messages causing additional work in the (usually central) point