BizTalk для обмена сообщениями в реальном времени

Question

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

Прежде всего, мы являемся магазином.NET и занимаемся обработкой медицинских транзакций. В настоящее время все наши продукты написаны для выполнения своей цели без единого кода. Большинство этих транзакций происходит через стандартный сокет TCP (например, HL7, использующий MLLP в качестве модели). Затем мы обрабатываем их и можем отправлять их одной или нескольким третьим сторонам для обработки через сокет. Наконец, мы отправляем ответ транзакции обратно клиенту. У нас есть довольно много приложений, которые работают так, как мы надеемся, на единой платформе.

Нам нужно, чтобы это работало очень быстро (<6 секунд для некоторых вещей), а также было очень отказоустойчивым при масштабировании. Мне сказали, что это то, где BizTalk превосходит.

Мой вопрос к вам, эксперты по BizTalk, звучит ли это как то, что BizTalk мог бы сделать хорошо? И любой другой совет, который вы можете дать для такой миграции?

Answer 1

FWIW, мой дубль:

Сильные стороны Biztalk по вашим требованиям

• Отображение сообщений является простым, и у вас есть выбор визуального отображения или xslt.
• Единообразие разработки - как только ваша команда разработчиков преодолела кривую обучения, она позволяет централизованную платформу для большинства видов работы EAI (т.е. вы можете продолжать добавлять новые приложения на свои серверы Biztalk, которые могут использовать существующие сообщения и процессы).
• Надежность транзакций - вы можете в значительной степени отключить BizTalk, и он хорошо справляется с восстановлением состояния без потери данных.
• Независимость от протокола - внутренне все это XML для Biztalk. Вы можете работать с клиентами с "особыми потребностями" с помощью широкого ассортимента адаптеров, доступных из коробки, без переписывания вашего приложения.
• Операция с минимальным обслуживанием - после развертывания и отладки приложений, настройки производственной среды и настройки задач обслуживания SQL и мониторинга (например, SCOM) BizTalk может быть отмечен как устройство.
• Масштабируемость (по цене) - BizTalk имеет множество ручек для масштабирования, и для масштабирования можно добавить несколько серверов. Однако в большинстве случаев мы обычно обнаруживаем, что узким местом является базовый SQL Server.

Недостатки

• Там будут некоторые проблемы, чтобы гарантировать задержки / максимальное время обработки. Например, необходимо серьезно подумать, когда BizTalk находится в состоянии крайней нагрузки, чтобы избежать состояний регулирования, которые могут вызвать очередь сообщений.
• Динамическая маршрутизация на некоторых протоколах / адаптерах немного нестабильна - вам, как правило, придется смешивать некоторый ваш собственный код, если вы попадаете в ту точку, когда становится неудобно управлять большим количеством статических портов отправки с фильтрами. например, если у вас есть 100 сторонних получателей [скажем, средств] - и 10 000 клиентов - [скажем, врачей / больниц], то перенаправлять потоки сообщений, исходящих из средств врачам, не будет весело. Если вы можете сохранить потоки сообщений, исходящие со стороны "многие", и используя синхронный протокол, вы можете избежать проблем с маршрутизацией.

FWIW Я использовал BizTalk в медицинской среде (но на стороне фонда, а не коммутатора), без особых проблем (при этом нам нужно было только подключить к 3 различным коммутаторам). Я предполагаю, что ваше требование <6 секунд относится к аутентификации аптек в реальном времени и т. Д. Я бы хотел разделить обработку в реальном времени и пакетную обработку (например, пакеты заявок) на разные узлы процесса или даже на разные серверы целиком. Это должно исключить возможность задержек в синхронной обработке (например, фарм-аутентификации), вызванных прибытием большой партии (например, заявок), которая может не иметь одинакового требования низкой задержки.