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)?

Answer 1

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."

Answer 2

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:

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