Many integration vendors define their offerings as an Enterprise Service Bus, but when you look at the various products, they don’t offer the same level of functionality. Let’s take a look at the differences between Integration Broker (IB) technology and an Enterprise Service Bus (ESB) to help you determine which you need and why.
Integration Broker
An Integration Broker facilitates point-to-point interactions between applications. They are designed to communicate program to program; they integrate previously independent applications or services at the application layer of software design.
Typically, data flows through a central IB, which is designed to provide data transformation and transport services between the sending and receiving application. IBs can simplify integration because they can connect systems with different data formats and data transfer methods.
More complex integration use cases that involve flows between multiple applications, content-based routing, conditional logic between steps or more formal message distribution services are out of scope for Integration Brokers.
Enterprise Service Bus
An Enterprise Service Bus is a software architecture model that provides loose coupling of services, allows services to be reconstituted into entirely different application contexts than when the services were first envisioned or developed, and promotes reuse of applications without the need to recode applications.
There is often debate on exactly what makes up an Enterprise Service Bus. Common capabilities include data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion, etc.
The one requirement that cannot be disputed is the need for a bus architecture—after all, it’s in the name. With a bus architecture, all systems follow the same standards and can share in a standard method of transferring data between systems. ESBs incorporate a publish-and-subscribe approach, which makes it easy for any application to plug in to the bus, as long as it meets the standards supported by the bus. A decentralized bus architecture can provide better scalability, when it has no single point of failure and is designed for large deployments.
One of the biggest differences between an Integration Broker and an ESB, it that ESBs support multi-step, cross-application process flows that incorporate complex messaging, reliability, and security requirements.
Do You Know Which Model Your Integration Technology Leverages?
When you look more closely at many of the open source “ESBs” you will see they are not really leveraging a bus architecture. When you look closer at what these tools offer, you realize they are providing tools that, in effect, are creating point-to-point integration. They rely on a web service or web APIs, the data mappings are ridged, and require custom scripts for transformation.
Messaging to Improve Reusability
A key component to an Enterprise Service Bus is a messaging layer. Introducing messaging greatly enhances service reusability. It provides great flexibility to the services themselves because they can subscribe to new data just by changing configuration. Messaging also provides great flexibility for applications created with services because other services or clients (like mobile applications) can be added without modification by supporting concurrent messaging models for integrating mixed application environments (JMS, web sockets, low latency, etc.).
The addition of a messaging infrastructure increases both the quality and scalability of applications. Quality is improved because messaging technology guarantees message delivery between services. Scalability is managed elegantly and seamlessly. Data is exchanged more efficiently for millions of request/responses, and/or additional instances of the services can be added to achieve X scaling (horizontal duplication).
In building applications for the enterprise and on the web, developers and architects need reliable, scalable, and high-performance messaging infrastructure for the delivery of information. Modern message brokers provide levels of security, reliability, and web scale performance (critical for mobile apps) that are simply not possible when using an Integration Broker.
Open source ESB vendors may lead you to believe that the unsupported open source projects like ActiveMQ will address your needs, but you need to be careful to evaluate whatever technology you plan to use in production to ensure it provides the reliability and scalability you require, with the level of support that’s expected in enterprise and web scale applications. You also need to determine the level of support you will be able to receive for the entire solution, not just the service bus portion.
These are just a few examples of the types of questions you need to ask to ensure the integration technology you choose does not restrict what you are able to achieve and does not end up costing you more than it should. For more details read 5 Emerging Use Cases for Cloud Integration.
