Basic Concepts: Hub/Spoke vs ESB

Note: This content has been edited for better readability…

Hub/Spoke architecture uses a centralized broker (Hub) and adapters (Spoke) which connect applications to Hub. A Spoke connects to an application and converts application data format to a format which the Hub understands, and vice versa. A Hub, on the other hand, brokers all messages and takes care of content transformation/translation of the incoming message into a format the destination system understands and routes the message. Adapters take data from the source application and publish messages to the message broker, which, in turn, does transformation/translation/routing and passes messages to a subscribing adapter which sends it to destination application(s). Having a single Hub makes a system with this architecture easy to manage but scalability takes a hit. At some point, as the number of messages increases, scalability gets dependent on hardware. Having a bigger box to scale the application has never been an ideal solution. So to overcome this limitation, most vendors have incorporated the concept of a federated hub and spoke architecture in which multiple hubs can be present. Each hub would have local metadata and rules as well as global metadata. Changes to global rules and metadata are automatically propagated to other hubs. Federated hub spoke architecture alleviates scalability issue while central management of multiple hubs makes this architecture easy to manage and brings down support cost.


Bus architecture uses a central messaging backbone (bus) for message propagation. Applications would publish messages to the bus using adapters. These messages would flow to subscribing applications using the message bus. Subscribing applications have adapters which would take a message from the bus and transform the message into a format required for the application. A key difference between hub/spoke and bus topology is that for the bus architecture, the integration engine that performs message transformation and routing is distributed to the application adapters. The bus architecture requires an application adapter

to run on the same platform as the original applications. Since each adapter has an integration engine and runs on same platform on which source and target applications run, this scales much better and is relatively complex to maintain compared to hub/spoke topology.


Enterprise service bus is an infrastructure to facilitate SOA. It provides an API which can be used to develop services and makes services interact with each other reliably. Technically, the ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from various services and application which are linked to the ESB. The current EAI landscape is seeing many vendors who offer enterprise service bus solutions and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based implementations which have been there in market for quite a long time now. Actually there is not much difference between ESB and proprietary buses except for a few subtle ones. The main difference between ESB and proprietary bus implementation is cost, which is significantly lower for ESB. The reason for this cost difference is twofold: (1) proprietary bus offers lot of built in functionalities as a suit of product which need to be developed for ESB implementations based on business requirement, (2) most proprietary buses use some proprietary formats to enhance the performance which increases the cost. ESB on the other hand is usually standard based, so it is a tradeoff between performance and cost between proprietary bus and ESB. The main advantage of ESB is that it costs much less then hub/spoke or bus based product suits, and is standards based. 



I am a technology and business consultant who provides state of the art software design services to rapidly growing and mature organizations using cutting edge technologies. Information Technology Professional with over 20 years of industry experience as a Software Architect/Lead Developer and Project Management Coach using service oriented (SOA/EIB) view of the software development process (Use Case/Story View, Class Design View, Database Design View, and Infrastructure View) and software design (Model-View-Controller based (MVC pattern/framework)). Coached PMs on various aspects of task and resource management and requirements tracking and tracing, and even filled in for PMs. Led teams of varying sizes mainly from the architect viewpoint: translating non-technical requirements into concrete, technical components and work units, identifying and creating reusable frameworks and design patterns, creating skeletal IDE projects with MVC wiring and config files, assigning app tiers or horizontal components to developers, making sure test team members have use cases and other work unit inputs to create an executable test/quality assurance plan, organizing meetings, ensuring enterprise standards and practices are adhered to, enforcing any regulatory and security compliance traceable from requirements/Solution Architecture Documents (SADs) all the way down to core classes in code, and so on Expertise includes designing and developing object-oriented, service/component-based software systems that are robust, high-performance and flexible for multiple platforms. Areas of specialization include Internet (business-to-business and business-to-consumer) e-commerce and workflow using Microsoft.NET technologies (up to current Visual Studio 2010/.Net Framework 4.0, MVC3/Razor View Engine, LINQ), TFS, Sharepoint 2007 (Task Mgmt, Build Script), Commerce Server 2007/2002 (basket and order pipeline), ASP.NET, ADO.NET, C#, Visual C++, Visual Basic.NET) and Java EE/J2EE, service oriented architecture (SOA) and messaging (MSMQ, MQSeries, SAP message handling) and more abstract enterprise service bus (ESB) designs, best patterns and practices, telecommunications and the offline processes of the enterprise. Provide detail estimates on budgets, guided design and development tasks with offshore teams, technical assessments of third party software tools and vendor selections, project/iteration planning and spring product backlogs, and level of effort for statements of work (including for offshore based development teams), including executive summary presentations as needed.

Tagged with: , , , , , , ,
Posted in Design, ESB, General SOA, Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Curve Monsters

Don't fear the curve, embrace it!

Soltis Consulting, Inc.

Business Concepts, Ideas, and Information

Ebonair Lifestyles

Accommodating the debonair lifestyles of ebony professionals everywhere

Affluent Blacks of Dallas

An online society for established and upwardly mobile black professionals, and those who aspire to be


Technology news, trends and analysis covering mobile, big data, cloud, science, energy and media

Thought Catalog

Thought Catalog is a digital youth culture magazine dedicated to your stories and ideas.

Trade News in Brief

International Economic Affairs & Relations / Regional & International Organizations / Global Commerce & Business

Software Bodyguard Blog for IT Security Protection

Info to Help You Protect Your Digital Assets and Identity

SOA Developers Blog

Helpful tidbits for service-oriented software developers

Samsona Corporation

If you can dream it, we can software it

%d bloggers like this: