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

Question

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

Я нашел это NServiceBus and Biztalk, описывая BizTalk как центральный брокер сообщений.

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

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

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

Answer 1

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

Answer 2

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

EDIT: Здесь a more-recent MS link, который попадает в особенности реализации.

Answer 3

BizTalk является спонтировал Майкрософт как имеющие возможности ESB - см BTS ESB toolkit

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

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

FWIW мы обнаружили БПС хорошие подходит для:

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

Biztalk Server withot "ESB Toolkit" Не является ESB. Из-за:

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

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

Answer 8

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

Для решения пары очков, сделанные здесь ...

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

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

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

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

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

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

Answer 9

К «EAI или ESB» Я предполагаю, что вы хотели бы знать, если BizTalk следует концентратор & спице или архитектуры шины.

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

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

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

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

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

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

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