Pros & Cons of ESB
An ESB is expected to exhibit the following characteristics:
- It is usually operating-system and programming-language agnostic; for example, it should enable interoperability between Java and .NET applications.
- It uses XML (eXtensible Markup Language) as the standard communication language.
- It supports web-services standards.
- It supports various MEPs (Message Exchange Patterns) (e.g., synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe).
- It includes adapters for supporting integration with legacy systems, possibly based on standards such as JCA
- It includes a standardized security model to authorize, authenticate and audit use of the ESB.
- To facilitate the transformation of data formats and values, it includes transformation services (often via XSLT or XQuery) between the format of the sending application and the receiving application.
- It includes validation against schemas for sending and receiving messages.
- It can uniformly apply business rules, enriching messages from other sources, the splitting and combining of multiple messages and the handling of exceptions.
- It can provide a unified abstraction across multiple layers
- It can route or transform messages conditionally, based on a non-centralized policy (i.e. no central rules-engine needs to be present).
- It supports queuing, holding messages if applications are temporarily unavailable.
- Key benefits
- Faster and cheaper accommodation of existing systems.
- Increased flexibility; easier to change as requirements change.
- Standards-based.
- Scales from point solutions to enterprise-wide deployment (distributed bus).
- Predefined ready-for-use service types.
- More configuration rather than integration coding.
- No central rules engine, no central broker.
- Incremental changes can be applied with zero down-time; enterprise becomes “refactorable”
- Key disadvantages
- Enterprise Message Model is usually required, resulting in additional management overhead. May not be a simple task to achieve many disparate systems collaborating on message standards.
- Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling.
- It normally requires more hardware than simple point to point messaging.
New skills needed to configure, manage, and operate an ESB. - Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point to point communications.
- Some critics remark that ESB require a significant effort to implement, but produces no value unless SOA services are subsequently created for the ESB
An ESB is expected to exhibit the following characteristics: It is usually operating-system and programming-language agnostic; for example, it should enable interoperability between Java and .NET applications. It uses XML (eXtensible Markup Language) as the standard communication language. It supports web-services standards. It supports various MEPs (Message Exchange Patterns) (e.g., synchronous request/response, asynchronous request/response, send-and-forget,…