So the obvious, and much publicised, question one asks when hearing about the Enterprise Service Bus, is what is it? Is it a style, is it a thing, or is it #*%!!
I have a particular take on this borne out of my own experience in having to justify such a thing within a large scale enterprise architecture programme. As per my earlier post on SOA==WS?, one’s perspective on SOA has a huge bearing how the ESB shapeshifter can be manifested within your problem-space.
In a traditional EAI landscape, we centralise the integration problem. This means that we enable the interacting systems to utilise local dialects when firing requests into the EAI space. The EAI brokers then deal with the transformation from external dialect, through the common, canonical dialect and into the external outbound dialects of the target systems (I am generalising in a big way however….). Difficult business integration problems are pushed away from the endpoints into the magic-in-the-middle, and this is where much of the EAI bad-press has come from, simply because it trades in peoples pain ! Would we need it if integration was easy ?
So my primary driver when looking to evolve my enterprise integration roadmap to support the unfolding SOA transformation, was to decentralise the pain and give it back to the owners. Not just to reverse the trend, but to drive convention and middleware infrastructure templates back to the edges of the relevant IT domains such that the runtime becomes federated.
This federation has an implicit but significant reliance upon consistency and contracts at the endpoints, whilst opening out a consistent, scalable messaging conduit (finally!) between the domain brokers. Standing back from this – we have clients and servers adderssing the transformation in/out of service contracts at the edge of their domain, with common representation, messaging and infrastructure management in the space between. The EAI Bus architecture was taking shape.
The most significant thing in my opinion was the reduction in diversity by prescribing inter-domain standards. Finally the EAI brokers didn’t need the full range of COTS and Technology adapters they were usually encumbered with, nor did they require the high-end process-management abstractions, and as a result the technical requirements on these components reduced dramatically.
Over time, the movement of endpoint-specific transformation, standard messaging and document convention and runtime independence to the endpoints became analagous with the vendorised ESB concept which came along subsequently.
However – my experience places the term ESB (and with major Emphasis on the ‘E’) as a scalable Enterprise framework, incorporating disciplined distribution of the integration problem space, and the consistency evolving int the messaging backbone.
I do see, and understand alternative perspectives (and I will use the term ‘eSB’ where the casing of the ‘e’ implies the technology being used in a less than Enteprise capacity. Where we see a the (systems not Enteprise) architecture incorporating a single messaging and transformation broker – supporting service contracts at the edges…implying the clients and servers are already emitting/consuming the expected dialect. I’m less convinced by this model and the shades of grey between this and my own perspective – purely because I am focused on the Enterprise ‘E’ in ESB as opposed to the ‘e’ in eSB…