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.
- ESB or not to ESB – original post
- ESB or not to ESB revisited – Part 1. What is an ESB?
- ESB or not to ESB revisited – Part 2. ESB and Hub n’ Spoke Architectures (this post)
- ESB or not to ESB Revisited – Part 3. API Layer and Grid Processing Architecture
Enterprise Service Bus Architecture
- 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
- 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
- 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.
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
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.