Enterprise Integration Zone is brought to you in partnership with:

Behind DotNetBlocks.com is a software engineer with over 10 years of experience in Microsoft technologies and is currently obtaining a Masters in IT. His primary focus is typically on software architecture, web applications, and interactions amongst various systems. Todd is a DZone MVB and is not an employee of DZone and has posted 47 posts at DZone. You can read more from them at their website. View Full User Profile

Enterprise Service Bus (ESB): Crucial to an SOA or Vendor Hype?

06.11.2012
| 8824 views |
  • submit to reddit

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:

Published at DZone with permission of Todd Merritt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jonathan Fisher replied on Tue, 2012/06/12 - 9:51am

 

The answer is easy: No. It's the fastest way to create a bottleneck in a scalable architecture. Furthermore, it promotes procedural programming rather than pure OO.

Using Dependency Injection and other patterns, frameworks like Spring largely solved the problems (durability, translation, loose coupling, mediation) that an ESB was meant to. Furthermore, Spring offers orders-of-magnitude greater performance than an ESB by avoiding pass-by-value semantics, which then negates the need for a tiered or federated architecture.

Today's goals are different than the ESB era.  Engineers are opting for simplicity, which yields performance, quicker bugs fixes, and faster iterations to production. When waterwall was king and proprietary protocols ruled the world, and computing was dominated by vendors instead of open source projects, and ESB was necessary. The world has changed though, and the need and desire for an ESB has sunset accordingly.


 

Mark Unknown replied on Tue, 2012/06/12 - 2:53pm

I agree with Todd. You do need an  ESB. You do not, however, need a product with the letters E-S-B on it. If you use Spring (i.e. Batch and Integration), to create your own ESB, well, you still have an ESB. That being said, what know about Spring (and I like Spring), it will not give you everything you need. 

Alessandro Santini replied on Wed, 2012/06/13 - 2:46pm in response to: Jonathan Fisher

Personally, I think that this answer falls in the "Solution Architecture IS NOT Enterprise Architecture" category.

I also fail to understand how an ESB should promote a procedural programming style. It is like saying that SOA could only be accomplished by using procedural programming.

Last but not least, many of my customers need to address topics like real-time business event processing across multiple channels, something that an ESB is naturally suited to address elegantly. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.