Is the Enterprise Service Bus Just Vendor Hype?
Is an Enterprise Service Bus (ESB) an important architectural piece to a Service-Oriented Architecture (SOA), or is it just vendor hype in order to sell a particular product such as SOA-in-a-box?
According to IBM.com, an ESB is a flexible connectivity infrastructure for integrating applications and services; it offers a flexible and manageable approach to service-oriented architecture implementation.
With this being said, it is my personal belief that ESBs are an important architectural piece to any SOA. Additionally, generic design patterns have been created around the integration of web services in to ESB regardless of any vendor.
ESB design patterns, according to Philip Hartman, can be classified in to the following categories:
- Interaction Patterns: Enable service interaction points to send and/or receive messages from the bus
- Mediation Patterns: Enable the altering of message exchanges
- Deployment Patterns: Support solution deployment into a federated infrastructure
Examples of Interaction Patterns:
- One-Way Message
- Synchronous Interaction
- Asynchronous Interaction
- Asynchronous Interaction with Timeout
- Asynchronous Interaction with a Notification Timer
- One Request, Multiple Responses
- One Request, One of Two Possible Responses
- One Request, a Mandatory Response, and an Optional Response
- Partial Processing
- Multiple Application Interactions
Benefits of the Mediation Pattern:
- Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently
- Design an intermediary to decouple many peers
- Promote the many-to-many relationships between interacting peers to “full object status”
Examples of Interaction Patterns:
- Global ESB: Services share a single namespace and all service providers are visible to every service requester across an entire network
- Directly Connected ESB: Global service registry that enables independent ESB installations to be visible
- Brokered ESB: Bridges services that are reluctant to expose requesters or providers to ESBs in other domains
- Federated ESB: Service consumers and providers connect to the master or to a dependent ESB to access services throughout the network
References:
- Mediator Design Pattern. (2011). Retrieved 2011, from SourceMaking.com: http://sourcemaking.com/design_patterns/mediator
- Hartman, P. (2006, 24 1). ESB Patterns that "Click". Retrieved 2011, from The Art and Science of Being an IT Architect: http://artsciita.blogspot.com/2006/01/esb-patterns-that-click.html
- IBM. (2011). WebSphere DataPower XC10 Appliance Version 2.0. Retrieved 2011, from IBM.com: http://publib.boulder.ibm.com/infocenter/wdpxc/v2r0/index.jsp?topic=%2Fcom.ibm.websphere.help.glossary.doc%2Ftopics%2Fglossary.html
- Oracle. (2005). 12 Interaction Patterns. Retrieved 2011, from Oracle® BPEL Process Manager Developer's Guide: http://docs.oracle.com/cd/B31017_01/integrate.1013/b28981/interact.htm#BABHHEHD
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Jonathan Fisher replied on Sat, 2012/10/27 - 10:08am
To answer the question "Is the Enterprise Service Bus Just Vendor Hype?" Yes, with absolute certainty. They are sales pipeline for vendors to be pitched as a cure-alls to executive IT management without any engineering input.
95% of the time you don't need an ESB, because patterns like dependency injection and frameworks like Spring have largely taken over the percieved need. ESBs are not lightweight, nor are they fast. They are complicated pieces of heavyweight architecture. They are not a scalability tool either, which is a common misconception and abuse. If your IT shop has < 500 engineers, you can automatically know that you do not need an ESB.
The only remaining sweet spot for an ESB lies in very large corporations that need to integerate legacy applications, or perhaps to integrate a competitor aquistion quickly, or to merge multiple (poorly designed) monolithic systems, or simply when the software engineering management clout does not exist in your organization to refactor and rewrite your existing codebase.
The underlying sales pitch of an ESB is that it can pay off mountains of technical debt that has been piling up from poor engineering management dictating technical design. You can't pay off technical debt by adding more architecture; you can only remove architecture, refactor, and simplify.
Source: Multiple tragic years using Mule, Sonic, and Websphere.
Mark Unknown replied on Mon, 2012/10/29 - 2:43pm