2016-07-28 13 views
0

Моя первоначальная цель - понять разницу между архитектурой ESB и архитектурой Hub-Spoke. Боюсь, я не могу понять это ясно, независимо от того, сколько ответов дано.как mulesoft (ESB) отличается от хаба и говорил?

Ниже мое понимание - ESB не является продуктом но топология архитектуры - ESB облегчает слабосвязанную интеграцию и снижает зависимость - Mulesoft ESB и другие ESBS в рынке предлагают больше, чем просто ESB характеристики - маршрутизация сообщений/Web поддержка услуг

Точка, которую я пытаюсь понять, - как она отличается от архитектуры HUB-SPOKE?

  • ESB говорит, что архитектура распределенной доставки сообщений делает ее работу таким образом, что зависимость снижается и возможно сокращение времени простоя. Но как? Это потому, что «адаптеры»/уровень интеграции находятся в исходном и целевом приложениях? если да, то почему Mulesoft или любые ESB на рынке предлагают, чтобы они предоставляли огромный диапазон адаптеров?

  • Если это вопрос архитектуры, это означает, что я могу иметь адаптеры в конце приложения и использовать ESB только для маршрутизации? и оставить адаптеры, предоставленные MUlesoft, неиспользованными?

  • Что еще более важно, как он отличается от концентратора? Технически, почему говорится, что «HUB-SPOKE» не позволяет распределенной архитектуры доставки сообщений?

Любая помощь в этом была бы высоко оценена. Заранее спасибо.

+0

Разницы между ESB и концентратором задается здесь http://stackoverflow.com/questions/35670583/esb-vs-eai-hub-spoke – ravthiru

ответ

1

ESB - это ориентированное на сообщение промежуточное ПО (MOM) плюс сервисы, которые предоставляет типичный контейнер приложений.

Таким образом, ESB помогает различным компонентам предприятия легко интегрировать интеграцию «точка-точка». Поставщик услуг/потребитель (компонент), однажды интегрированный с ESB, может разговаривать с любыми компонентами, которые уже интегрированы, что снижает затраты на интеграцию «точка-точка».

ESB говорит, что архитектура распределенной доставки сообщений позволяет работать таким образом, что зависимость снижается и возможно сокращение времени простоя. Но как? Это потому, что «адаптеры»/уровень интеграции находятся в исходном и целевом приложениях?

как же ESB добиться того, что

  1. Все компоненты интегрирующих с ним следует говорить в общего формата данных (сообщений)

  2. маршрутизации и фильтрации на основе заголовка сообщения

  3. Поддержка нескольких моделей связи/интеграции

    а) Синхронные против Asynchronous
    б) запрос только (с/без Ack)
    с) запрос с ответом

Какие дополнительные услуги предоставляет ESB предоставить?

  1. развертывания Application Service
  2. пулы Thread
  3. очереди сообщений
  4. Мониторинг и статистика
  5. Кластеризация Поддержка
  6. Высокая доступность Поддержка

почему Mulesoft или любые ESBSна рынке предлагают, чтобы они обеспечили огромный диапазон адаптеров ?

Обычно используемые компоненты, такие как служба БД, файловые службы, Rule Engines, почтовая служба, службы FTP уже интегрированы в ESB/или адаптеры уже написаны, так как только компонента интеграции с ESB он легко может использовать эти общие услуги с небольшой конфигурацией или без нее

Если это вопрос архитектуры, это означает, что я могу иметь адаптеры в конце приложения и использовать ESB только для маршрутизации? и оставить адаптеры, предоставленные MUlesoft, неиспользованными?

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

Что еще более важно, как он отличается от концентратора? Технически, почему говорится, что «HUB-SPOKE» не позволяет распределенной архитектуры доставки сообщений?

Нет никакой разницы, если реализация архитектуры обеспечивает все функции и службы ESB. Но некоторые говорят, что с ESB мы можем распространять компоненты на разных машинах, чтобы обеспечить масштабирование и отказоустойчивость.

0

Основное различие между узлом/говорил и топология шины является то, что для архитектуры шины, интеграция двигатель, который выполняет преобразование сообщений и маршрутизацию распределяется к адаптерам приложений, а не централизовать его к одному «концентратору»