Reading Time: 8 minutes

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 Architecture

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

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

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 hub and spoke 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