Enterprise Service Bus (ESB) : To use or not to use

We no longer bring services together within a program but we bring them together in an environment which no longer needs programming. This environment is an ESB, an Enterprise Service Bus. Services are grouped together through an orchestrate/choreographic function. This gives us very dynamic, simple and viewable application constructions.

One of the main strengths of an ESB is processing messages. Message in, message out, perhaps with protocol or format mediations applied. When the requirements clearly call for message processing, an ESB is going to have several advantages, including the ability to handle greater complexity in the transformations. If the requirements call for one of the basic ESB functions, such as message routing, transformation or protocol mediation, an ESB would be the clear choice.

Another strength of an ESB is performance. An ESB is designed to be able to handle large volumes of messages. If, for example, the requirements say that there will be 200,000 messages per day, the ESB would clearly be the better choice.

If the requirements are data-centric, an ESB is the clear choice.

ESB is well suited to scenarios where loose coupling, scalability and robustness are required.

A checklist to judge whether your application needs ESB

• Are you integrating 3 or more applications/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.



• Will you really need to plug in more applications in the future?



• Do you need to use more than one type of communication protocol? One Http, another is JMS etc.



• Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? This is true if you have multiple versions of the service and you need to forward the request to a service based on the content in the request.



• Do you need to publish services for consumption by other applications?



• Do you have more than 10 applications to integrate?



• Do you really need the scalability of an ESB? It’s very easy to over-architect scalability requirements of an application. ESB scales down as well as up making it a popular choice for ‘building in’ scalability. However, there is a price to be paid for this since you are adding a new technology to the architecture.



• Do you need to use the security features provided in ESB. ESB provides Inbound and outbound security which can be handled at various levels. We have transport level, authentication, authorization built into ESB implementations.



• Do you wbant to manage software load alancing within ESB.

If the above points do not satisfy, then we better not go with ESB as in that case ESB will be nothing more than a pain.

But if you think your application satisfies all the above points then ESB is a advantage. Also, ESB does not have performance issues and will be better than the delegator that most of us implement.

Please see below few reference to ESB

What is ESB : http://en.wikipedia.org/wiki/Enterprise_service_bus

Open source ESB for Java : http://java-source.net/open-source/enterprise-service-bus

Oracle service bus (best in the industry) : http://www.oracle.com/appserver/esb.html

Whether to use ESB or not : http://rossmason.blogspot.com/2009/07/to-esb-or-not-to-esb.html