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

Ответ 1

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

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

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

FWIW мы обнаружили, что BTS подходит для:

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

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

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

Ответ 2

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

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

Таким образом, BizTalk из коробки - это не более EAI или ESB, но может работать как с несколькими разработчиками, применяемыми к этой проблеме.

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

EDIT: более поздняя ссылка MS, которая попадает в особенности реализации.

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

• Сначала это контракт, вам нужно сначала создавать типы сообщений.
• Необходимо сначала спланировать весь сценарий, чтобы свести к минимуму влияние изменений.
• Для изменений требуется развертывание, которое увеличивает время простоя.

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

Ответ 9

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

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

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

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

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

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

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

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