Introduction
This article is to bring clarity to terms ESB, EMB and provide a clear distinction. In addition this discuss the EAI and related architecture.
Enterprise application integration is a business need to make diverse applications in an enterprise including partner systems to communicate to each other to achieve a business objective in a seamless reliable fashion irrespective of platform and geographical location of these applications. It is a business need and business never dies it only evolves.
EAI comprises of message acceptance, transformation, translation, routing, message delivery and business process management. Usually messages transportation is asynchronous but for a business need it can be synchronous as well. There are two basic architectures to achieve this, bus and hub/spoke architecture. Both of these can be used to develop services and then it also becomes service orientated architecture.
Hub Spoke Architecture
Hub/Spoke architecture uses a centralized broker (Hub) and adapters (Spoke) which connect applications to Hub. Spoke connect to application and convert application data format to a format which Hub understands and vice versa. Hub on the other hand brokers all messages and takes care of content transformation/translation of the incoming message into a format the destination system understands and routing the message.
Having a single Hub makes system with this architecture easy to manage but scalability takes a hit.
Bus Architecture
Bus architecture uses a central messaging backbone (bus) for message propagation. Applications would publish messages to bus using adapters. These messages would flow to subscribing applications using message bus. Subscribing applications will have adapters which would take message from bus and transform the message into a format required for the application.
Bus architecture is seen as a distributed services architecture which delivers messaging middleware, intelligent routing, and XML transformation in conjunction with a flexible security framework and a management infrastructure for configuring, deploying, and monitoring the services.
The following table captures the difference between ESB and EMB based on the parameters
| Parameters | ESB | EMB |
| Definition | An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. An ESB performs the following: · Matches and routes communications between services · Converts between different transport protocols · Transforms message formats between requestor and service · Identifies and distributes business events from disparate sources An ESB is based on open standards | Message Broker works on a HUB-SPOKE model. Hub-and-spoke architectures consist of a centralized hub that accepts requests from multiple applications that are connected to the centralized hub as spokes. A Message broker is adopted for following reason · It provides a focal point for applications and reduces the links between applications from n² links to n links · The hub provides a layer of insulation and functionality between the spokes, thus enabling spoke applications to be removed and replaced without other spokes being disrupted in any way |
| Architecture | At the heart of the ESB architecture is the enterprise services bus, a collection of middleware services that provides integration capabilities. The bus provides the medium for messages to reach their destinations. | In hub-spoke approach, all integrated applications connect through a central server. Thus, a new system or application only needs to be connected with the hub to be automatically integrated with other applications that also are connected with the hub. The integration server acts as a message broker to control communication, data translation, and process interaction among the connected systems. |
| Scalable | ESB provided services are themselves distributed in the sense that different components come and play their role in providing the infrastructure services promised by the ESB. | HUB (usually a message broker) is a monolithic piece of software. |
| Capabilities | Capabilities of an ESB can be plugged into other ESB's to allow the user to get the benefit of mix and match of services. | Capabilities of the HUB cannot be used as plugged components in another HUB. |
| Standards | Services provided by ESB, deployment and installation of these services and interfacing b/n these services is standard based (JBI). | Services provided by the HUB and the interfacing between these services is not standard based and is usually proprietary standards driven, leading to a risk of vendor locking. |
| Configuration | ESB user can choose which services need to installed and used and which services they want to leave per instance of the ESB. | The hub, being a monolithic piece of software can be used only in an 'all or nothing' mode. |
| Installation Effort | Moderate Effort | Less installation effort compared to solutions with bus architecture. |
| Cost | Low coz it does not use proprietary format | High |
| Scalability | Highly Scalable | High if federated architecture is used otherwise limited by the hardware of box used to host Hub |
| Values | Better Performance Complex and Difficult to Administer Bus architectures are more difficult to manage for resource-strapped IT groups, but they're better-suited for large-scale environments | Central Point for Failure HA becomes critical Better for Companies with limited IT Resources and environment that handles handful of transaction |
| Product | IBM ESB with DataPower BEA AquaLogic Service Bus Mule OpenESB Fuse | IBM Message Broker BEA WebLogic Integration |
