Является ли BizTalk ESB?

Question

Я изучаю архитектурные шаблоны, Enterprise Services Bus (ESB) точно.После прочтения этой статьи Enterprise Integration , и практически без опыта я задаюсь вопросом, имеет ли BizTalk ESB или это просто EAI (Hub / Spokes или Bus)?это NServiceBus и Biztalk , описывающие BizTalk как центральный брокер сообщений.

С учетом других сред ESB (NServiceBus и Rhino Service Bus)Эти структуры не имеют центральной точки для обработки сообщений.

Является ли Biztalk EAI, а не ESB?

Большое спасибо

Answer 1

BizTalk наказывается Microsoft как обладающая возможностями ESB - см. BTS ESB toolkit

Однако термин «ESB» охватывает очень широкое поле , иесть много субъективности в отношении точного определения ESB.ИМХО, есть слабые места в утверждении BizTalk о том, что он является всеобъемлющим в качестве ESB (в определении термина> 2010).

• BTS возникла в эпоху EAI «Hub-and-Spoke», до того как ESB получил широкое распространение.
• BTS больше подходит для асинхронных процессов, чем синхронных процессов - задержки будут варьироваться в зависимости от нагрузки на систему, состояния дросселирования и т. Д.
• BTS громоздка, когда дело касается простоты управления версиями.сервисы и схемы (требуется новое развертывание)
• BTS громоздка, когда речь идет об управлении МНОГИМИ сервисами (например, использование BizTalk в качестве фасада для всех 5000 ваших корпоративных SOA / веб-сервисов будет болезненным)

В то время как мы нашли, что BTS хорошо подходит для:

• всех наших синхронных и асинхронных EAI (то есть формализованных интеграционных контрактов между основными системами LOB и с торговыми партнерами), а такжеБольшое количество адаптеров помогает интегрировать большое количество протоколов.
• Для бизнес-процессов иВозможности бизнес-мониторинга
• Обеспечение надежности транзакций и доставки - Biztalk имеет возможность повторять, отслеживать и возобновлять приостановленные сообщения, что полезно в ненадежных сетях или при интеграции с ненадежными системами.

Обновление , с некоторыми дополнительными сравнительными впечатлениями

• BTS очень централизована - в конечном счете, даже многосерверный кластер / группа BizTalk зависит от Sql-Server.Продукты ESB на основе очередей имеют тенденцию быть более децентрализованными (логически и физически), поэтому потеря нескольких конечных точек или серверов очередей не должна приводить к краху всего предприятия.
• Многие ESB на основе очередей построены на технологиях с открытым исходным кодом.стремление избежать привязки к одному поставщику
• Многие современные ESB, похоже, применяют товарный подход для масштабирования.Масштабирование с такими продуктами, как BizTalk, может стать дорогостоящим.
• С другой стороны, нельзя недооценивать возможности мониторинга и администрирования коммерческих предложений, таких как BTS, - убедитесь, что любой рассматриваемый вами ESB имеет достаточный аудит, инструменты, повторные попытки.и диагностические возможности (WMI / SNMP / SCOM и т. д.) - вам понадобится панель мониторинга для контроля состояния вашей шины, и нет ничего хуже, чем незнание того, куда отправлено сообщение.Здесь централизация администрирования и диагностики это плюс.

Answer 2

BizTalk - это платформа для обмена сообщениями и управления рабочими процессами, на которой вы можете строить поведение и возможности ESB. Чтобы упростить это и стандартизировать реализацию ESB в BizTalk, Microsoft выпустила BizTalk ESB Toolkit - набор рекомендаций, шаблонов и кода.

Концепции EAI и BPM существуют уже давно, поэтому многие компании используют BizTalk для решения этих проблем. Компаний, которые размещают полный ESB на сервере BizTalk, гораздо меньше, и их внедрение, безусловно, замедлилось с появлением WCF / WF / NServiceBus и, конечно, Azure Service Bus.

Итак, в итоге, BizTalk из коробки не является ни EAI, ни ESB, но может работать как с несколькими разработчиками, применимыми к проблеме.

Answer 3

По " EAI или ESB " Я предполагаю, что вы хотели узнать, следует ли BizTalk архитектуре Hub & Spoke или Bus.

С точки зрения шаблонов архитектуры, интеграционные решения примерно подпадают пододин из двух шаблонов -

• Концентратор и луч : это включает в себя централизованный брокер сообщений, отправляющий сообщения различным получателям, в то время как все отправители отправляют только свои сообщенияэтому брокеру.Таким образом, ни отправители, ни получатели не должны знать друг о друге.Это обычно то, что многие люди называют EAI (хотя абсолютно возможно реализовать решение EAI, которое следует шаблону BUS).Решения по этой схеме легко разрабатывать и администрировать.Вся логика маршрутизации управляется централизованно в одном месте - в концентраторе.Но, как вы уже догадались, у этого есть явный недостаток - единственная точка отказа.Если хаб выходит из строя, все останавливается.Кроме того, эта модель не очень хорошо масштабируется.

• BUS : Решения для корпоративной интеграции, разработанные по этому шаблону, обычно называют ESB.Здесь нет разумной центральной власти.Все отправители публикуют свои сообщения в автобусе.Приемники должны быть достаточно умны, чтобы определить, какие сообщения предназначены для них, и снять их с шины.Таким образом, отправители и получатели должны знать только о шине.Но здесь логика маршрутизации распределена между получателями, поэтому нет единой точки отказа.Также эта модель отлично масштабируется.Однако такие решения довольно сложны и сложны в администрировании.

В связи с вопросом, какой шаблон следует за BizTalk, он является гибридом обоих этих шаблонов.

КонцентраторПодобный внешний вид очень очевиден благодаря централизованному Messaging Engine и центральной базе данных MessageBox .Это дает простоту и легкость администрирования, которая типична для хаб-подхода.

Но если вы посмотрите на архитектуру BizTalk, можно получить Host с Host Instances. распределено по нескольким серверам.Также возможно настроить разные базы данных BizTalk, такие как MessageBox, Tracking, Ent SSO и т. Д., Настроенные на разных серверах.Это делает решения BizTalk более масштабируемыми и более устойчивыми к сбоям, чем обычные реализации концентратора - это поведение обычно приписывается шинному подходу.

Надеюсь, что это отвечает на ваш вопрос.

Answer 4

BizTalk - это больше, чем ESB, но, безусловно, отвечает всем требованиям. Эта ссылка немного устарела, но отвечает на ваш точный вопрос.

РЕДАКТИРОВАТЬ: Вот более свежая ссылка MS , которая входит в особенности реализации.*

Answer 5

BizTalk, безусловно, ESB. EAI - более свободная концепция - BizTalk, безусловно, может быть развернут для поддержки EAI, а также может сделать гораздо больше.

Answer 6

Я согласен с большинством сказанного здесь. BizTalk - это универсальное решение EBS для всех, даже с инструментарием EBS.

Чтобы ответить на пару замечаний, сделанных здесь ...

• BTS больше подходит для асинхронных процессов, чем для синхронных процессы - задержки будут варьироваться в зависимости от нагрузки на систему, состояние дросселирования и т. д.

Хосты BizTalk с неизменными значениями по умолчанию не идеальны для низкой задержки. Но эти хосты предназначены для настройки. Стандартная конфигурация не подходит для любой ситуации, где требуется пропускная способность. В моем опыте хождения в организацию, где BizTalk был исключен, в середине его всегда находилась ненастроенная установка одного хоста. Это несколько аналогично созданию таблиц в dbms без индексов, получению проблем с производительностью и утверждению, что сама dbms отстой.

• BTS громоздка, когда дело касается простоты управления версиями сервисов и схемы (требуется новое развертывание)

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

Что касается конечных точек службы, BizTalk может размещать веб-службы без использования IIS (BizTalk может использовать HTTP.SYS для размещения точно так же, как IIS). Для размещения службы обработки в BizTalk нужно просто импортировать привязку, которую можно выполнить, не останавливая ничего в BizTalk. В этих конечных точках также можно реализовать управление версиями (например, http: ... / thing / v1, http: ... / thing / v2 и т. Д.).

В любом случае ~ 5 лет прошло, я уверен, что вы уже пришли к выводу:)

Answer 7

Biztalk Server с "ESB Toolkit" не является ESB.Из-за следующего:

1. Это сначала контракт, сначала нужно создать типы сообщений.
2. Сначала необходимо спланировать весь сценарий, чтобы минимизировать влияние изменений.
3. Изменения требуют развертывания, что увеличивает время простоя.

Что касается вашего вопроса, да BizTalk Server является продуктом EAI

Answer 8

Абсолютно! Biztalk происходит из опыта EIS, что идеально подходит для ESB в качестве объединительной платы инфраструктуры для сервис-ориентированных архитектур, охватывающих гибридные технические платформы.

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

Это Microsoft, поэтому вы получаете то, за что платите, но все же стоит посмотреть.

Answer 9

BizTalk может использоваться как EAI, так и ESB.

Что касается ESB, архитектура сервера BizTalk имеет подписку публикации, одно сообщение может быть опубликовано в окне сообщений, которое действует как магистральная шина обмена сообщениями. Это сообщение может быть получено одной или несколькими системами назначения, которые подписаны на это сообщение. Конечно, есть больше возможностей и возможностей, которые вы можете получить с помощью сервера BizTalk, например, инструмента mapper и использования компонентов конвейера.

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

Answer 10

BizTalk может выполнять как ESB, так и EAI, в зависимости от того, как вы разрабатываете свои приложения biztalk.