Должны ли мы ввести BizTalk / ESB?

Question

Моя компания собирается внедрить новую архитектуру, в которой мы предложили BizTalk (мы - магазин Microsoft) в качестве Enterprise Service Bus (ESB) в среде SOA (не цитируйте Service Oriented Ambiguity).

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

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

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

К сожалению, в истории компании (до моего назначения) первоначальная попытка представить BizTalk не удалась, но я уверен, что у него есть место, и я могу его доставить.

Возможно, мой вопрос не столько о BizTalk, но о том, является ли ESB хорошей идеей в моем описанном сценарии, когда имеет смысл вводить ESB?

Answer 1

Хорошо. Руководство ESB по Biztalk от группы по предписанию архитектуры - http://msdn.microsoft.com/en-us/library/cc487894.aspx

Мы используем BizTalk, где я работаю, чтобы делать много вещей. У него есть несколько простых точек интеграции. У нас есть несколько более сложных точечных интеграций с быстро настраиваемыми adpaters и конвейерами. У нас есть корпоративные системы интеграции для основных клиентов, информация о продукте и цена и предложение на заказ. Все это отдельные приложения BizTalk. Некоторые довольно маленькие, а некоторые довольно большие. В основном мы использовали BizTalk, чтобы делать точки-точка / многие точки шлейфов без использования шаблона ESB. Внедрение ESB подразумевает уровень управления самой шиной и стандарты сообщений предприятия, которые будут разрешены на шине. Если вы будете взаимодействовать с большим количеством систем с большим количеством различных форматов - ESB имеет большой смысл. Если интеграции, которые вы хотите достичь, менее амбициозны, ESB может быть излишним. При этом, это чистая и расширяемая архитектура. Вам придется принять решение о стоимости.

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

Answer 2

Мне только что задал тот же вопрос коллега, и вот что я ему сказал:

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

Только если кажется, что интеграция решение должно масштабироваться до высокого объемы с низкой задержкой (есть фантастический асинхронный механизм публикации-подписки), и вы нужна отказоустойчивость (есть избыточность, масштабирование и повтор сообщений особенности) и управление над решение (есть бизнес-активность Мониторинг) вы бы действительно веские аргументы, чтобы рассмотреть возможность использования BizTalk. И если вы знаете, что там несколько будущих интеграций, которые будет необходимо, то это становится действительно принуждение к использованию BizTalk.

С другой стороны, вам нужно сделать уверен, что навыки доступны для управлять вещью. Требуется время учиться и сдвиг парадигмы для разработчики систем. тем не мение его построили с нуля в .NET и SQL Server, так что довольно много знакомства в оснастке и концепции.

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

Также я недавно внедрил новый ESB Toolkit 2.0 на клиенте и очень доволен им. Маршрут (см. Шаблон «Схема маршрутизации» http://www.enterpriseintegrationpatterns.com/RoutingTable.html), который действительно делает создание веб-сервисов простым, гибким и быстрым.

Answer 3

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

Итак, думаю, BizTalk подойдет для того, что вы хотите сделать? категорически да. Думаю ли вы, что вы правы, избегая соединения типа «точка-точка» - тоже да, но, как и в случае любого рефакторинга для повторного использования, включая любую инициативу SOA, вы должны учитывать, сколько изменений, а теперь многократного повторного использования вы ожидаете, чтобы решить, насколько далеко вы выполняете упражнение "развязка".

Answer 4

Я думаю, что имеет смысл иметь брокера данных, основанного на описанных вами требованиях, но я лично не думаю, что BizTalk будет лучшим выбором в вашей ситуации. Для того типа интеграции, который вы описали, я бы посмотрел на устройство с аппаратным брокером данных. Некоторые из них, которые я видел, хорошо работают, это IBM DataPower, устройство Vordel и устройство Layer7. Для типов вызовов, для которых вы будете использовать это, идеально подойдет устройство. Они обеспечивают маршрутизацию, преобразование и трансляцию, а также защищают от таких вещей, как отравление схемами. Они также будут обрабатывать авторизацию, аутентификацию и аудит, связывая его с вашим хранилищем пользователей (полагаю, у вас есть хранилище пользователей Active Directory на основе среды, которую вы описали, но оно также будет работать с LDAP)

Устройством будет BizTalk или любое другое программное решение с точки зрения стоимости владения (без затрат на поддержку), и производительность любого устройства, вероятно, превзойдет BizTalk на порядок.

Answer 5

Вам нужно поговорить о задержке и пропускной способности. Все остальное просто бла-бла.

Answer 6

Это очень четкая картина. Обычно, когда вы отправляете сообщение из Системы A в Систему B, вы выполняете прямое преобразование из формата Системы A в формат, который хочет Система B. Если у вас есть ESB, вы преобразуете сообщение Системы A в формат ESB (т. Е. Общий PO, Order и т. Д.), А затем в формат, требуемый для системы B. Это преобразование двух по сравнению с 1, а также шаблон шины требует В каждом сообщении есть глагол (т.е. добавление, удаление, обновление и т. д.). Это действительно важное различие, и именно это делает ESB очень полезным при интеграции с большим количеством участвующих систем.