ESB == SOA++???
Something is really troubling me. You may have noticed that I have been pondering the notions of SOA and, more recently, ESB and that I have some issues with the latter. More concerning even that the notion of companies building their enterprises on top of entierely proprietary infrastructure which promise UEI (Utopian Enterprise Integration) is the confluence of terms:
Why is our industry so caught up with jumping on bandwagons and adopting terminology that has no meaning or clear, well defined, broadly adopted value proposition?
Take for example the fact that almost everyone talking about ESB also talks about SOA at the same time. Some claim that ESB's enable the building of SOA's. Some claim that SOA enables ESB ...
STOP IT!!! Will someone PLEASE turn down the volume????
It's like the industry has forgotten what we're trying to do and that nobody is able to see beyond where we stand today. We have EAI but that's not good enough - EAI is too "edge condition" for most EAI technology vendors' tastes and it seems like they're promoting this "new" ESB terminology that seems to be an attempt to centralize their offerings at the core of the enterprise instead of at the periphery.
But where is the link to SOA.
As I have opined before ... the whole "SOA" situation is just nasty. There are a million incompatible definitions of SOA, few of which have a great deal in common. If you read the definition of SOA from any technology vendor, it's amazing to see just how well their definition fuses with their currently or soon to be available technologies, products and services. Because no two technology companies have the same product and feature set, there are therefore often chasm-like differences between the vendors' definitions of SOA. This is one of the primary reasons Microsoft has not jumped on this bandwagon ... there isn't a single wagon to jump onto - there's just a random collection of vehicles trundling around - some are rickshaws, some are 747's, others are ocean-going supertankers; all are trying to be Hummers that perform like Lamborghinis, with the fuel-economy of Hondas and deliver value like a Kia!
This is such a shame. There is enormous value in the notion of "Service Orientation" (SO) ... that is, SO defined abstractly from any technology, product or service offering.
Remember back to the early days of OO? Remember how we used to be able to articulate what OO was regardless of any development tool/language/platform/system??? THAT is what we should be aiming towards when we talk about SO and Services, not some utopian and yet flawed proprietary marketing spin-fest aimed purely to sell more bits to unsuspecting customers in a desparate attempt to retain/regain market share.
SO has as much to do with [insert technology of choice here] as OO had to do with C++, Smalltalk, Delpi or Eiffel.The notions of SO are, if properly defined, pure, clean, abstract and generally applicable to any given distributed systems platform.
Why then all this mess, confusion and muddle about the linkage between SO(A) and ESB. To my eyes, there is none. They are orthogonal concepts. One is about integrating disparate, incompatible systems, the other is about building distributed systems in the future that avoid being disparate and incompatable and communicate openly, freely, securely and reliably by default.
But then, maybe I am wrong. Maybe I am missing something here. Please comment and correct me if I am!
