Can someone explain an Enterprise Service Bus to me in non-buzzspeak?

Question

Some of our partners are telling us that our software needs to interact with an Enterprise Service Bus. After researching this a bit, my instinct is to say that this is just buzz speak for saying that we need to have a platform-indpendent way to pass messages back and forth. I'm just trying to get a feel for what our partners are telling us. Am I correct in dismissing our partners' request as just trying to get our software to be more buzzword-compliant, or are they telling us something we should listen to (even if encoded in buzzspeak)?

What technologies are you using now for message routing and event triggering and what not? — buckbova, Jun 16 '10 at 17:41
ESB is buzz speak for async message delivery, usually through some message queuing system, which in most "enterprisey" products means high latency and high configuration and maintainance trouble depending on the ESB implementation you choose to work with. — , Jun 16 '10 at 17:42
Our employers and clients are investing a lot of money on ESB technology and I'm not thrilled that the highest rated answer says it's just buzz-speak. I found it odd that the two answers that didn't dismiss ESB as nothing more than a buzzword neither floated to the top nor were accepted. I'm offering a bounty to see if it produces a better answer or something I'd consider to be a better outcome on the existing answers. — T.Rob, Mar 12 '11 at 19:33

score 38 · Accepted Answer · answered Jul 01 '10 at 03:12

Although ESB is based on messaging, it is not "just" messaging and not just a buzzword.

So if you start with plain old async messaging, the early networks tended to be very point-to-point. You had to wire up (i.e. configure through some admin interface) each connection and each pair of destinations and if you dared to move anything around invariably something broke. Because the connection points were wired by hand these networks never achieved high connection density. The incremental cost was too high and did not scale. There was also a lot of access control and policy embedded in the topology. The lack of connection density actually favors this approach to security, even though it inhibits flexibility.

The ESB attempts to address these issues with...

Run-time resolution of destinations/services/resources
Location transparency
Any-to-any connectivity and maximum connection density
Architected for redundancy, horizontal scalability, failover
Policy, access control, rules externalized from topology
Logical messaging network layer implemented atop the physical messaging network layer
Common namespace

So when your customer asks for ESB compatibility, they want things like the above. From an application standpoint, this also implies...

Avoiding message affinities such as requirements to process in strict sequence or to address requests only to specific nodes instead of to a generic network destination
Ability to resolve destinations dynamically at run time (i.e. add another instance of a queue and it automatically starts getting traffic, delete one and traffic routes to the remaining nodes)
Requestor and provider apps decoupled from knowing where each other "lives". Requestor makes one connection, regardless of how many services it might need to call
Authorize by policy rather than by topology
Service provider apps able to recognize and handle dupes (as per JMS spec, see "functional duplicate" due to session handling)
Ability to run multiple active instances of a service provider application
Instrument the service provider applications so you can inquire on the status of the network or perform a test without sending an actual transaction

On the other hand, if your client cannot articulate these things then they may just want to be able to check a box that says "works with the ESB."

+1 Very informative answer. I would add (from my non-expert view) that the bigger and more complex a company's IT infrastructure is, the more value an ESB can have. Managing several thousand connections is a much different beast than managing a few dozen. — peteorpeter, Mar 17 '11 at 21:29

score 26 · Answer 2 · answered Mar 16 '11 at 18:23

26

I'll try & keep it buzzword free (but a buzz acronym may creep in).

When services/applications/mainframes/etc... want to integrate (so send messages to each other) you can end up with quite a mess. An ESB hides that mess inside of itself (or itselves) so that an organisation can pretend that there isn't a mess and that it has something manageable. It then wraps a whole load of features around this to make this box even more enticing to the senior people in an organisation who'll make the decision to buy such an expensive product. These people typically will want to introduce a large initiative which costs a lot of money to prove that they are 'doing something' and know how to spend large amounts of money. If this is an SOA initiative then vendors various will have told them that an ESB is required to make the vendors vision of what SOA is work (typically once the number of services which they might want passes a trivial number).

So an ESB is:

A vehicle for vendors to make lots of money;
A vehicle for consultants to make lots of money;
A way for senior executives (IT Directors & the like) to show they can spend lots of money;
A box to hide a mess in;
A total PITA for a technical team to work with.

answered Mar 16 '11 at 18:23

Neil

993
9
9

4

And the snarky answer rockets to the top. :-/ Hard to tell if this is sincere or tongue-in-cheek but either way I was hoping to generate an answer that would be provide some guidance to someone who, for better or worse, ends up working on an ESB project, and this isn't it. I'm not arguing that anything here is untrue (that'd be a fun conversation over a few drinks) only that it isn't terribly productive for someone who needs to get up to speed and produce some results. – T.Rob Mar 17 '11 at 23:30
I'm sorry if it appears snarky. It wasn't intended in that way. In my experience working both in organisations which have adopted these products, and with the products, I have found these & other things to be true for me. The OP, whose question I focused on, seemed interested in whether such a request should be dismissed as a request for buzzword compliancy. My view, which I perhaps should have been more specific & explicit in relaying, is that it can, but that as a marketing angle for a vendor it does have value, if not in a moral sense perhaps. – Neil Mar 18 '11 at 13:27
Reading the question again, I think not enough detail is given to know if the OPs product would benefit from being interoperable with, but, that if interop was valuable then focusing on ESB compatibility is likely an unhelpful perspective. Rather any choice of interop strategy should take into account the intended interop scenarios (freq/latency/msg size/etc). This might lead to different approaches from db based integration, to REST, to events over MQ, to sync SOAP, etc... Any ESB ought to be able to work with any of these. The value prop being left to the client to consider in their context. – Neil Mar 18 '11 at 14:00

score 9 · Answer 3 · answered Jun 16 '10 at 17:44

After researching this a bit, my instinct is to say that this is just buzz speak for saying that we need to have a platform-indpendent way to pass messages back and forth

You are correct, partially because the term ESB is always nice word that fits well with another buzzword, legitimate or not - which is governance (i.e. helps you manage who is accessing your endpoints and reporting metrics - Metrics btw is what all the suits like to see, so that may be a contributor)

Another reason they might want a platform neutral device is so that any services they consume are always exposed as endpoints from a central location, instead of a specific machine resource. The ESB makes the actual physical endpoints of your services irrelevant to them, which they shouldn't care much about anyway, but that enables you to move services around however they will only consume the ESB Endpoint.

Apart from a centralized repository for Discovery, an ESB also makes side by side versioning of services easier. If I had a choice and my company had the budget, we would have purchased IBM's x150 appliance :(

Thirdly, a lot of more advanced buses, like SoftwareAG's product if I recall, is natively able to expose legacy data, like from data sitting on main frames as services without the need for coding via adapters

I don't know if their intent is to leverage all the benefits an ESB provides, or as you said, make it buzzword compliant.

score 7 · Answer 4 · answered Jun 16 '10 at 17:37

After researching this a bit, my instinct is to say that this is just buzz speak for saying that we need to have a platform-indpendent way to pass messages back and forth

That's about right. Sometimes an ESB will go a little bit further and include additional features like message delivery guarantees, confirmation/acknowledgement messages, and so on. The presence of an ESB also usually explicitly or implicitly creates a new protocol where none previously existed, which is another important consideration. (That is, some sort of standard or interface has to be set regarding the format of the messages.)

Am I correct in dismissing our partners' request as just trying to get our software to be more buzzword-compliant, or are they telling us something we should listen to (even if encoded in buzzspeak)?

You should always listen to your customers, even if it initially sounds silly. It's usually worth at least spending the effort to decide what's going on. Reading between the lines, what your partners probably mean is that they want a way for your service to integrate more easily with their own services and products.

score 6 · Answer 5 · answered Jun 16 '10 at 17:40

An enterprise service bus handles the messaging between systems in a standard way. This allows you to communicate with the bus in the same exact way across all your platforms and the bus handles the actual translating to individual communication mechanism needed for the specific endpoint. This means you write all your code to talk to the bus using a common messaging scheme and the bus handles taking your common scheme and translating it so the endpoint understands it.

score 0 · Answer 6 · answered Mar 18 '11 at 20:46

The simplest explanation is to explain what it provides:

For many years companies acquired different platforms and technologies to achieve specific functions in their business from Finance to HR. These systems needed to talk to each other to share data so middleware became the glue that allowed them to connect. Before the business knew it, they were paying for support and maint on each of these systems and the middleware. As needs in the business changed departments decided to create their own custom solutions to address special needs rather than try to make the aging solutions flexible enough to meet their needs. Before they knew it, they were paying to support and maintain the legacy systems, middleware, and custom solutions. With new laws like Sarbanes Oxley, companies need to have better information available for reporting purposes. A single view requires that they capture data from all of the systems. In addition, CIOs are now being pressured to lower costs and increase customer service. One obvious solution is the eliminate redudant systems, expensive support and maint contracts, and high cost legacy solutions which require specialists to support. Moving to a new platform allows for this, but there needs to be a transition. There are no turnkey solutions that can replicate what the business does. To address the needs for moving information around they go with SOA because it allows for information access through a generic entity. If I ask for AllEmployees from the service bus it gets them whether it is from 15 HR systems or 1. When the 15 HR systems becomes 1 system the call and result does not change, just how it was done behind the scenes. The Service Bus concept standardizes the flow of information and allows IT managers to conduct transitions behind the bus with no long term effect on upstream users.

Can someone explain an Enterprise Service Bus to me in non-buzzspeak?

6 Answers6