Biztalk против MSMQ - PullRequest
       31

Biztalk против MSMQ

1 голос
/ 10 февраля 2012

Нам нужно отправить XML-сообщения между системой торговой точки и веб-службой Java (за пределами нашей сети). сообщения содержат очень конфиденциальные данные. Обмен сообщениями должен быть безопасным, транзакционным и высокодоступным (24/7) с аварийным переключением. Решение требует разработки брокера, который выполняет следующие действия:

  • Опрос сообщений из POS системы (3 типа сообщений)
  • сделать некоторые преобразования в сообщениях
  • переслать часть сообщения на веб-сервис java
  • сохранить часть сообщения в базе данных
  • уведомляет систему POS о результате

Исходя из этих несколько упрощенных требований, считаете ли вы, что Biztalk будет излишним? будет MSMQ / WCF сделать трюк здесь?

Спасибо за вашу помощь

Амин

Ответы [ 3 ]

4 голосов
/ 10 февраля 2012

IMO, если у вас есть возможность получать и доставлять сообщения асинхронно, тогда MSMQ (или другое промежуточное программное обеспечение, ориентированное на сообщения) будет очевидным выбором для надежного транзакционного транспорта, независимо от остальной части решения.Журналирование MSMQ также может использоваться для аудита и отладки (но вам понадобится стратегия архивирования журнала).

Для требований Опрос, Маршрутизация, Отображение / Брокер и Аудит вы можете выбрать BizTalk,другие продукты ESB и EAI или решение для самостоятельной работы.

Как вы и предлагали, трудно обосновать кривую стоимости и обучения BizTalk для одного сценария обмена сообщениями, такого как этот, - вы, вероятно, могли бы потерпеть неудачу.NET Windows Service (например, с использованием WCF, Workflow Foundation, областей транзакций, некоторого XSLT для отображения и уровня доступа к данным) в течение нескольких дней.

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

3 голосов
/ 10 февраля 2012

Хотите ли вы иметь пропускную способность для разработки, мониторинга и поддержки своего собственного решения?Если вы не возражаете против этого, то, возможно, хорошо подойдет путь для настраиваемого решения на основе .net, MSMQ / WCF.

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

  • secure
  • транзакционный
  • надежный (сообщения не теряются)
  • высокая доступность (24/7)
  • аварийное переключение
  • архитектура адаптера (включает адаптеры опроса)
  • преобразований
  • работа с внешними веб-службами
  • возврат коррелированных ответов обратно в исходную систему (т. Е. Управление сквозным процессом)
  • использование посредника(Вы специально перечислили это, и BizTalk - это брокер; пользовательский MSMQ и WCF означает, что он не использует брокера)

Если BizTalk необходимо опросить систему POS, вам не нужно беспокоиться об использовании MSMQ.BizTalk может надежно обрабатывать передачу сообщений (они сохраняются в SQL Server, а MSMQ сохраняет сообщения на диск).

Обратите внимание, что единственный способ сделать MSMQ высокодоступным - это кластеризовать его.Так или иначе, вам нужно что-то кластеризовать.

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

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

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

Создание собственного кода клиента .NET дляРабота с веб-сервисом Java, вероятно, займет много времени, независимо от того, каким путем вы идете.С BizTalk это означает запуск мастера на конечной точке или на WSDL.С WCF это означает, что вы все делаете вручную или с помощью инструмента svcutil.

1 голос
/ 10 февраля 2012

Вы должны использовать MSMQ для транспортировки в любом случае.

Если вы используете MSMQ из .NET, вы должны знать его ограничение: 4 МБ на размер сообщения.

С другой стороны, BizTalk имеетАдаптер MSMQ, который преодолевает это ограничение (если второй сервер BizTalk прослушивает другую сторону канала). Кроме того, BizTalk предоставляет вам такие функции, как: легко настраиваемое отслеживание сообщений, карты визуального преобразования.Его можно настроить и в кластере (только для версии Ent.).

Но вопрос в том, можете ли вы (или хотите) позволить себе лицензии biztalk и оборудование для его серверов (это медленнее, чем пользовательское решение .net)..

...