Разница между Hub, Spoke и ESB

Точного ответа здесь нет, поскольку можно говорить о ESB как о конкретном шаблоне проектирования, либо как о дискурсе об эволюции средств интеграции ПО и SOA.

ESB как шаблон проектирования означает, что вы управляете связью между различными службами, используя шину, к которой клиенты могут легко подключаться и отключаться. Обычно это делается путем принуждения их к использованию стандартных форматов данных и протоколов, в то время как с Hub and Spoke вы можете использовать настраиваемые соединители и преобразования данных для каждого клиента. Это ограничивает количество проблем, которые могут возникнуть при выполнении нескольких интеграций, но у вас все еще может быть единая точка отказа в ESB.

ESB как дискурс (или маркетинговый термин) - более сложный вопрос, когда люди спорят о том, что такое «истинный ESB». Некоторые люди говорят, что вам нужна модульная архитектура, в которой вы можете выбирать, какие компоненты развертывать, или вам нужна возможность распределять компоненты по разным машинам, чтобы обеспечить масштабирование и отказоустойчивость. В крайнем случае вам нужно будет развернуть даже ваши преобразователи данных в виде распределенных сервисов.

Я не знаю, имеете ли вы это в виду, когда говорите is physical deployment the difference here?, но на самом деле основное различие между концентраторами и ESP заключается в том, что их система связи находится в different Layer..

Когда мы говорим о ESP, мы имеем в виду software architecture model, а концентратор — строгое hardware connecting topology.

Профессионально этот hardware topology (набор концентраторов) реализует ESP, но между ними существует четкая линия на уровнях связи.

Из здесь

ESB — это следующее поколение технологии корпоративной интеграции, пришедшее на смену EAI (hub-spoke).

• Умные конечные точки. ESB позволяет создавать архитектуры, в которых больше интеллектуальных функций размещается в точке, где приложение взаимодействует с внешним миром. ESB позволяет каждой конечной точке представить себя в качестве службы с использованием таких стандартов, как WSDL, и устраняет необходимость в уникальном интерфейсе, написанном для каждого приложения. Интеллектуальные средства интеграции могут быть изначально развернуты на конечных точках (клиентах и ​​серверах). Канонические форматы обходят стороной в пользу прямого форматирования полезной нагрузки в целевой формат. Этот подход эффективно устраняет большую часть сложности, присущей продуктам EAI.
• Распределенная архитектура. В то время как EAI – это чисто центральный подход, ESB – это упрощенная распределенная архитектура. Централизованный концентратор имел смысл, когда каждое взаимодействие между программами должно было быть преобразовано в канонический формат. ESB распределяет гораздо больше логики обработки по конечным точкам.
• Отсутствие интеграционных стеков: поскольку клиенты использовали продукты EAI для решения большего количества проблем, каждый поставщик добавлял стеки собственных функций, связанных с продуктом EAI. Со временем эти интеграционные стеки стали монолитными и требуют глубоких знаний для использования. ESB, напротив, представляют собой относительно тонкий слой программного обеспечения, к которому могут применяться другие уровни обработки с использованием открытых стандартов. Например, если пользователь ESB хочет развернуть определенный инструмент управления бизнес-процессами, его можно легко интегрировать с ESB с помощью стандартных отраслевых интерфейсов, таких как BPEL, для координации бизнес-процессов.

Непосредственное краткосрочное преимущество подхода ESB заключается в том, что он обеспечивает тот же общий эффект, что и подход EAI (звезда-втулка), но при гораздо более низкой совокупной стоимости владения. Эта экономия достигается не только за счет снижения затрат на оборудование и программное обеспечение, но и за счет сокращения трудозатрат благодаря использованию распределенной и гибкой среды.