What is an ESB and what is it good for?

Question

At a previous job, there was lots of talk about "Enterprise Service Bus" (ESB). I read parts of a conceptual book about it, but never really understood how you would implement/integrate it in concrete terms. I'm familiar with SOA/queueing/directory services/etc. but I don't understand what exactly an ESB is.

Is it a concrete thing (service/server/broker/etc.) that you just hook all your apps up to it in different ways, or is it more just a conceptual way to design systems?

Any explanations or links to good examples would be greatly appreciated. Thanks.

Answer 1

It's a fairly high level concept of abstraction. The central concept is that the ESB provides the middleware and interfaces that allow businesses to connect their applications without writing code.

This could include mediation to reconcile incompatible protocols, data, and interaction.

The idea of a central bus on which everything passes gives opportunity for additional layers of abstraction. Using industry standards to "plug" other applications, clients, and such into this bus makes it so that connecting new services, data sources, clients with disparate needs is relatively easy.

Actual implementations

As far as actual implementations, that's the domain of very large enterprise support businesses. While it's very buzzwordy, the goal is an ideal that on some small level can be understood through comparison with the internet:

Similarity to Internet

One big communications bus with widely different uses and data, but all running standardize protocols.

One can, in fact, write an HTTP to FTP connector that would allow browsers to access FTP sites without invoking an FTP client (usually built into the browser now).

Mashups

Mashups demonstrate an interesting implementation - take some bus route data from the San Francisco authority, map from google, and sushi bar locations from yahoo with ratings and run a simple query that gives you the closest sushi bar, weighting it so that you'd be willing to travel a little further for a better bar.

All completely different services, incompatible by themselves, but using standard connectors (yahoo pipes, for instance) they can be pulled together into a cohesive and useful whole.

-Adam

Answer 2

Disclaimer: I work for IBM and consult on WebSphere ESB, an IBM product designed to build ESBs with. The following are my opinions and don't necessarily reflect IBM's position.

An ESB is different things to different people, unfortunately.

To me, an ESB is a any technology that you can insert into an SOA (Service-Oriented Architecture), allowing you to connect disparate systems together. It often performs the functions of protocol transformation, message modification, routing, logging, acting as a security gateway, and so on. For example, you might use an ESB to expose a service previously only available as a Web Service as a JMS-based service as well.

In this respect, ESB implementations (or to be more precise, software sold to build ESBs with - such as that I consult on) are often technologically similar to what used to be known as a messaging or queueing broker, although the purpose is somewhat different, because (as the acronyms imply) it's oriented around services rather than moving messages from one place to another. How important the distinction is technologically is a matter of opinion.