ESB and Hub n’ Spoke Architectures – ESB or not to ESB revisited Part 2

In my last post, ESB or not to ESB revisited – Part 1, I put some definition around what an ESB really is, today I’m going to describe two integration architectures, ESB and Hub and Spoke, providing the benefits and considerations for each.

Previous Posts:

Enterprise Service Bus

ESB Characteristics

  • Canonical message format; typically XML, often standards-based
  • The message is the contract between systems
  • Each integrated system has an adapter to translate from the application format to the canonical format
  • Each system is decoupled by a ‘messaging bus’
  • ESB architecture is usually stateless; state is attached to the message

ESB Benefits

  • Well-defined architecture makes it fairly easy to design around and scope a project
  • Built for Scale; no state to manage, Adding new participants does not add load on a single point in the architecture
  • Easy to onboard new systems by introducing a new participant on the bus
  • Reliable; the bus decouples applications. A failure in one system does not impact other systems
  • Easier to migrate legacy systems. Backend applications are abstracted by the adapter; this means you can run new and legacy systems in tandem and route messages based on your migration needs

ESB Considerations

  • There is up front overhead associated with the ESB architecture, including:
    • Defining canonical message format.  This is not an easy process since you need to define a message that suits the different needs of the applications you are integrating.  Typically there is a common section for all applications and then additional payloads or attachments to allow for varied content.
    • Defining adapter architecture. Given that you create an adapter for each application, you’ll want to make it as standard as possible so that it can be stamped out quickly for new applications. Typically the adapter takes care of data translation, validation, message routing, etc.
  • There is a learning curve for developers since ESB have new concepts such as endpoints, connectors, and components that are not always familiar. Also, the ESB architecture is typically asynchronous and uses messaging for communication, many developers will not have thought about systems in this way. Though with the rise of JavaScript frameworks, asynchronous systems are becoming the norm.

Recommendation

An ESB architecture is best suited for integration projects that, i) include more than a few applications and, ii) plan to be extensible allowing for the addition of more applications in the future. An ESB architecture is typically selected for strategic projects where the upfront cost of developing the architecture is part of the planning.

Hub and Spoke Architecture

Rooted in the Enterprise Application Integration (EAI) days, the architecture integrates applications from a central location. Each call out to a system or application returns to a central hub for further processing.

Hub and Spoke Characteristics

All systems integrated from a single location; the Hub

  • Usually, work application data formats directly; no canonical message
  • State is maintained in a shared database
  • To scale the architecture, the hub is clustered

Hub and Spoke Benefits

  • An easy architecture to get started with since there are no architecture concepts for the developer to consider
  • Works well for a small number of integration points (applications)
  • Can be scaled by clustering the hub, vertical scaling not horizontal scaling

Hub and Spoke Considerations

  • Single point of failure
  • Not good for high number of transactions
  • Difficult to manage over time if more systems keep getting added
  • Hard to scale, need to run a bigger box to get more performance; cluster for reliability

Recommendation

Hub and Spoke architecture is a great way to get started with integration, such as a proof of concepts.  It is also suitable for small integration projects or to serve as an integration layer for an application.

In my recent talk at PhillyJUG, I covered these two architectures plus two others that I will describe in my next post. There were a lot of questions at my JUG presentation, so please feel free to post questions here.

Read on about the next part of this series ESB or not to ESB revisited – Part 3.

Follow: @rossmason@mulesoft


 


We'd love to hear your opinion on this post


8 Responses to “ESB and Hub n’ Spoke Architectures – ESB or not to ESB revisited Part 2”

  1. Can you briefly explain what’s the relationship between Mule and Apache ActiveMQ? Are they competing technologies or they compliment each other?

  2. Mule is an ESB, ActiveMQ is a JMS provider what in the ESB architecture is called MOM (Message Oriented Middleware). In an ESB infrastructure a MOM can be one of the available transport.

  3. […] ESB or not to ESB revisited – Part 2. ESB and Hub n’ Spoke Architectures […]

  4. […] the benefits and the considerations of each. You can read the original post and follow-up parts 1, 2, and 3. Here is a quick […]

  5. […] ESB or not to ESB revisited – Part 2. ESB and Hub n’ Spoke Architectures […]

  6. […] Einige Leser fragen sich jetzt bestimmt, worin sich ESB von Hub and Spoke unterscheidet. In der Grafik ganz einfach: ESB nutzt eine Linie oder ein Rechteck, Hub and Spoke einen Kreis als zentrales Element. Ansonsten interagieren in beiden Fällen n Systeme über n Verbindungen mit einer Zentrale. Der Unterschied liegt in den Daten: Beim ESB wird erwartet, dass auf dem Bus ein einheitliches Datenformat vorliegt. Bei Hub and Spoke reden die einzelnen Systeme in verschiedenen Formaten miteinander. Im worst case benötigt jedes System n-1 Datentransformatoren, wenn es mit allen anderen System redet. Mehr dazu: ESB or not to ESB revisited – Part 2. […]

  7. […] so now i am on the job and really need to understand it… an with these blog entries(1, 2), of a Mule ESB founder its really simple and clear This entry was posted in concepts and […]

  8. “Adding new participants does not add load on a single point in the architecture”

    Except on the messaging bus itself, no?