This won’t hurt a bit. Just take a deep breath and relax – while we introduce you to the…
If you’re a developer, you’re probably thinking something along the lines of:
“Is it… ?”
“No, it can’t be – surely ….”
“By Knuth ! Look at the efferent coupling on that thing ! We’re all going to die !”
If you ever presented a design like that to anyone – you’d probably be out of a job. You can, however replace the blob with a more traditional ESB long-box representation and dangle the services below it (This is one of oldest marketing tricks known to man, also known as the “homeomorphic swap”)
It still has the same topology and the same coupling issues that are indicative of “something that knows too much” and “a certain brittleness”, but now – you have become architect material.
As an architect, you might be tempted to make an argument that everything is fine and dandy, because it’s loosely coupled.
If there were no hardwired endpoints, and you had a service discovery mechanism powered by a Wintermute AI at your disposal – you would probably get away with it (The odds are – there are – and you don’t). That is, as long as your architecture only needs to support read operations.
The “Bus” concept is somewhat analog to a semantic sucker punch. The word itself practically induces associations to some kind of Matrix like hosting mehcanism that suddenly made distributed computing easy.
The one thing the analyst forgot to tell you all those years ago at that expensive conference - was that an ESB is a piece of software that is running on a piece of hardware. There is a high probablity that your ESB actually obeys the laws of physics. I.e. it doesn’t really work, does it ?
REST didn’t kill SOA – there was no need.