In my last post 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:

• 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

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 istypically 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 architecture 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.

Follow: @rossmason, @mulesoft

 

Related posts:

1. ESB or not to ESB Revisited – Part 1
2. Mule 3 Architecture, Part 2: Introducing the Message Processor
3. Activiti + Mule ESB – Part 2
4. To ESB or not to ESB

Filed under: Mule ESB, Tech Ramblings | Social tagging: architecture > esb > hub and spoke > Mule ESB