Benefits of an enterprise service bus

Question

Where can I find some information on the uses and benefits of an enterprise service bus (ESB)?

I am looking for information about:

1. the kinds of problems and ESB helps to solve
2. the alternatives to an ESB - and the tradeoffs in selecting between them
3. what you need to do as a developer to build ESB-compatible systems

I'm looking for a finer level of detail than just Wikipedia or online marketing brochures from vendors. Ideally, some example code would help to clarify what's involved in taking advantage of an ESB. Information from a .NET or Java perspective would be the most useful.

Thanks.

Answer 1

There is a decent 3-part series over at IBM regarding ESB that's pretty concept oriented and vendor agnostic (for the most part). I have found lots of good stuff on ESB by poking around IBM's site. There is also some decent info and videos and stuff over at the BizTalk site.

Answer 2

I'd suggest To ESB or not to ESB to start with, written by the creator of Mule.

Answer 3

In addition to the sites that were already mentioned. You should read this article on "Don't use an ESB unless you absolutely have to". It was written by the CTO of MuleSource, one of the most popular open source ESB's available. Not exactly an answer to your question, more of making a point to ask yourself "Do I need an ESB"?

Answer 4

ESB's are a good way to implement Enterprise Integration Patterns.

Kinds of problems that an ESB helps to solve

• You have a number of protocols you'd like to normalize to a single protocol (e.g. FTP, email, SOAP, XMPP, etc. to a messaging system) e.g. ActiveMQ. This lets you decouple the implementation of services from the protocol.
• You want a consistent way to hook services into this architecture so that they can listen for messages, process messages and generate messages (Message Endpoints, Channel Adapters etc.).
• You may want a managed container to deploy these various components into (e.g. ServiceMix, Mule)
• You may want a number of prebuilt components and adapters into various protocols (e.g. ServiceMix, Mule and Camel have a lot of pre-built components).
• You may require long running workflows. Business Process Management is often something that is provided alongside an ESB (Apache ODE plugs into a number of Open Source ESBs).

Alternatives to an ESB

The alternatives really depend on the problem that you're trying to solve.

• To provide distributed services, people often use application servers exposing services via some point to point RPC protocol (like EJBs over RMI or Web Services over HTTP). So, rather than putting a message onto a 'bus', a client directly calls a server.
• To respond to specific protocols, you could just build a client that responds to that protocol for example writing an application that listens for emails using JavaMail or one that listens to XMPP using Smack. If your problem is constrained to one or two protocols it may not be worth bringing in a full ESB.

What you need to do as a developer to build ESB-compatible systems

This will depend on the ESB you select, although given that most of the good ones are designed to call out into all sorts of protocols as well as host POJOs, there isn't much you should need to do build ESB compatible systems. It is worth trying to make your code asynchronous.

For examples, Apache Camel probably has the most succinct configuration, here's a tutorial.

Answer 5

Check out this Hanselminutes podcast: http://www.hanselman.com/blog/HanselminutesPodcast176NServiceBusWithUdiDahan.aspx It answers a few questions that you should really ask yourself before implementing a service bus.