Definitions: Enterprise Service Bus

Definition

The term “Enterprise Service Bus” can be used to mean an architectural style, but is more widely used to refer to software that carries information between applications

Business applications

ESBs are used for integrating systems and applications. ESB as a technology evolved from enterprise application integration. Rather than  using point-to-point connections between applications, you can send messages or “calls” through the ESB, which routes them to the appropriate  applications.  In practical terms, this educes the cost of custom coding and can make your systems more efficient.

Think of it this way: In the real world, a bus is used to eliminate the need for an individual to walk or drive from place to place. In the software world, applications do not need to have a direct connection to each other if they have access to an ESB.

But ESBs are not simply couriers, unquestionably delivering messages. They can also “translate” messages for legacy applications that do not support messaging. In simple terms, this means the ESB will put the data in  a format the legacy application can use. This is done with an adapter, and most  ESBs include numerous adapters.

An ESB can also be used to enforce business rules. According  to a 2006 special report on ESBs published in Visual Studio Magazine, an ESB can add specific services to messaging, including:

1. Security.
2. Priority-based routing.
3. Content-based routing.
4. Adapters for different types of code, which are  used for communicating with legacy systems.

Finally, since ESBs generally include a repository that assists with prioritizing messages, many organizations use ESBs as a backbone  for their service-oriented architecture (SOA). The services can be stored in  the ESB repository. The ESB then delivers and mediates services.

ESBs are often deployed when Web services form the core of the SOA. However, it's important to remember that while many organizations have  found ESBs helpful, they are not required to build a SOA. In fact, there has  been some debate about whether ESBs are detrimental as a foundation for SOA.

Deployment Concerns

There is disagreement in the industry about when ESBs should be used, and to what extent. For instance, while an ESB can be used to enforce  business rules related to security and message priority, Chief Technologist and  IT Toolbox blogger Eric Koch warns against putting business logic in the ESB layer:

“I have worked on several ESB or integration broker rip-outs. Invariably developers put too much business logic into the ESB layer and do not  practice fundamental architecture principles such as layering and separation of concerns. They turn the ESB into the intermediary of choice, creating a service  hub. This defeats or overlaps the role of the service registry and complicates the overall architecture.”

While ESBs are common tools in enterprise architecture, not everyone is a fan. At QCon London 2008, ThoughtWorks’ chief scientist Martin Fowler and Dr. Jim Webber, global head of architecture for ThoughtWorks, argued that most enterprise-scale ESBs are so bloated, they can hinder agility. Instead, they advocate Web-centric design. Of course, their criticism of ESBs attracted critics of its own.

Others are concerned about the proliferation of ESBs. Since ESBs are used to send messages between different systems and applications,  vendors have increasingly added ESB solutions to their software platforms. As a result, organizations find they're running multiple types of ESBs. Some have questioned  whether this could cause problems – essentially, requiring you to integrate  solutions designed to solve integration problems.

The counter-argument is that ESBs are designed for integration, so integrating multiple ESBs is easy and of little concern.

Related Knowledge Network Content