BizTalk: Последовательная доставка сообщений

Это еще одно описание Последовательной Доставки сообщений [Ordered Delivery —  OD] в BizTalk Server.

Здесь английская версия. Английская версия, но уже в TechNet.

Главное описание OD — на MSDN.

Здесь я обсуждаю детали реализации OD.

Замечания по поводу OD

  • OD режим (режим упорядоченной, последовательной доставки) противоположен режему Параллельной Доставки. Параллельная доставка — это самый производительный режим; OD — менее продуктивный режим.
  • Протоколы, поддерживающие стандарт WS-ReliableMessaging и протоколы, такие как MSMQ, сами по себе поддерживают OD. Другие протоколы, такие как  FTP, File, SQL, SMTP, не имеют понятия о каком-либо «порядке»в последовательностях.
  • Обычно приложение BizTalk-a — это только часть полного маршрута на пути доставки сообщений.
  • Есть два основных подхода к реализации OD:
    • Все шаги на всем маршруте доставки сообщения поддерживают OD независимо друг от друга.
    • Система, которая является потребителем сообщений, сама восстановливает порядок сообщений, сама беспокоится о потерянных сообщениях и о дублированных сообщениях. Канал доставки сообщений может поддерживать OD и может не поддерживать OD.
  • Порядок — понятие относительное. Последовательности могут строиться относительно только одного или нескольких параметров. Например, порядок сообщений может поддерживаться только относительно сообщений, относящийся к одним и тем же компаниям, либо компаниям + отделам внутри компаний.

OD и архитектура BizTalk

  • MessageBox — это реализация Очереди Сообщений (Message Queue). OD — это одна из внутренних характеристик MessageBox.
  • BizTalk по умолчанию работает в режиме Параллельной Доставки.
  • Есть три части в архитектуре обработки сообщений BizTalk-а, не относящихся к MessageBox: Receive Locations; Orchestrations; Send порты.
    • Receive Locations поддерживают OD на уровне транспортных протоколов (к примеру,  в MSMQ и WCF адаптерах).
    • OD в Orchestrations реализовано с помощью шаблона Последовательных Конвоев (sequential convoy pattern).
    • Send порты поддерживают OD для всех статических адаптеров.
  • BizTalk Pipelines (входящие в состав Receive и Send портов) всегда обрабатывают сообщения последовательно, используя потоки (streams).

OD и порты

Чтобы заставить Receive Locations работать в режиме OD, мы устанавливаем параметр  “Ordered Delivery” в Receive Location Transports, в тех транспортах, где это поддерживается. Если этот параметр установлен, BizTalk Adapter для соответствующего транспортного протокола автоматически обеспечивает реализацию OD.

Чтобы заставить Send порты работать в режиме OD, мы устанавливаем параметр  “Ordered Delivery” в Send портах. Если этот параметр установлен, BizTalk MessageBox автоматически обеспечивает реализацию OD.

OD Send Port instance работает как singleton сервис, т.е.сервис, который может быть запущен только в единственном экземпляре. После того, как он стартует, он постоянно остается в рабочем режиме (Running state). Он не изменит режим, если мы сделаем рестарт его Host Instance. Если надо, мы можем вручную удалить этот сервис, но по умолчанию он работает неограниченно долго.

OD и Orchestrations

MessageBox реализует шаблон Последовательного Конвоя, чтобы обеспечить OD.  [См.Using Correlations in Orchestrations]. Смотрите детальное описание этого шаблона здесь BizTalk Server 2004 Convoy Deep Dive.
Это не просто шаблон, которому должны следовать разработчики при создании Orchestration. Внутри MessageBox реализованы специальные механизмы, поддерживающие этот шаблон.

OD и Orchestration: Пример

Рассмотим четыре Orchestrations, реализующих разные подходы в последовательной доставке сообщений.

Первое — ProcessNoOrder Orchestration. На рисунке это сервисы находящиеся в колонке All in Parallel. Оно обрабатывает все сообщения без всякого порядка. По одному экземпляру ProcessNoOrder Orchestration будет создаваться для обработки каждого нового входящего сообщения.

Последнее — ProcessInOrder Orchestration обрабатывает все сообщения в одной последовательности.  На рисунке это сервисы находящиеся в колонке All in Order. Только один экземпляр ProcessInOrder Orchestration будет создан и все сообщения будут обрабатываться им по очереди.

ProcessInOrderByCompany Orchestration обрабатывает сообщения в нескольких последовательностях, собранных (кореллированных) (correlated) в соответствии со значением параметра Company (A, B, C, D и т.д.). Отдельная очередь создается для каждого нового значения Company. Сообщения внутри очередей обрабатываются последовательно. Очереди для разных Companies независимы. Отдельный экземпляр ProcessInOrderByCompany Orchestration будет создаваться для каждого нового значения Company.

ProcessInOrderByProduct Orchestration работает абсолютно так же, как и ProcessInOrderByCompany Orchestration но очереди собираются в соответствии со значением параметра Product (xx, yy и т.д.).

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

Обсуждение

Быстродействие

По умолчанию все экземпляры Orchestration и Messaging сервисов работают в режиме Parallel Delivery, обеспечиая тем самым максимальную производительность.

Если включить режим Ordered Delivery в Send порту, BizTalk будет инициировать экземпляр Send порта как единственный (singleton) сервис. Он будет запускаться всегда только в единственном экземпляре. У нас здесь нет гибкости, которую мы имеем с Orchestration, где мы можем настроить «степень параллельности» и где мы можем контролировать время жизни экземпляров.

Send порт может работать в двух OD режимах, может быть в двух состояниях,  включен или выключен:

  • OD выключен: много экземпляров порта, по одному на каждое входное сообщение; одно сообщение на очередь; максимальная производительность.
  • OD включен: всегда только один экземпляр порта на все сообщения; все сообщения в одной очереди; минимальная производительность.

Orchestration может работать также в двух OD режимах OD. Чтобы «изменить» режим, нам надо изменить дизайн Orchestration. Это не просто изменение одного параметра в настройках.

  • OD выключен: много экземпляров Orchestration, по одному на каждое активирующее входное сообщение; одно активирующее сообщение на очередь; максимальная производительность.
  • OD включен: один или несколько экземпляров Orchestration, один на каждую новую коррелированную последовательность сообщений; одна очередь на каждую такую последовательность; производительность от минимальной до максимальной, в зависимости от коррелирующих параметров.

Тщательно спроектировав коррелирующий набор параметров мы можем настроить производительность Orchestration. Например, если мы хотим, чтобы все документы, относящиеся к одной компании, обрабатывались последовательно, мы включаем параметр НазваниеКомпании в коррелирующий набор. Если на тысячу документов приходится сотня компаний, то производительность будет ближе к максимальной. Но если есть только две компании, то производительность будет ближе к минимальной, так как в первом случае документы будут обрабатывать сотня экземпляров Orchestration, а во втором — только два экземпляра. Чтобы увеличить производительность для второго варианты, мы можем добавить в коррелирующий набор дополнительный параметр, к примеру Отдел. В результате будет больше уникальных сочетаний НазваниеКомпании +НазваниеОтдела и будет стартовать больше экземпляров Orchestration.

Orchestrations и Зомби

Так называемые Зомби — это специфическая проблема шаблона Последовательных Конвоев. (См. BizTalk: Instance Subscription and Convoys: Details статью с описанием этой проблемы.) Эта проблема может быть уменьшена, но не может быть полностью устранена. Мы ожидаем, что в новой версии BizTalk Server эта проблема будет решена.

BizTalk Server version Next, Последовательная доставки и Зомби

Есть вероятность, что BizTalk Server version Next добавит автоматический режим OD в Orchestrations, реализует шаблон, подобный реализованному в Send портах.

Мы увидим три новых параметра в Orchestration: Ordered Delivery, Stop on Exception, и Recycle Interval (in seconds).

Параметр Ordered Delivery работает очень похоже на такой же параметр в Send порту. Теперь нам не надо вручную строить Последовательный Конвой. Не нужен больше Цикл (Loop) внутри  Orchestration.

Было бы замечательно, если бы эти параметры были бы доступны в run-time.

Если параметр Ordered Delivery установлен как True, Orchestration работает как Singleton. Первый Receive будет принимать все коррелированные сообщения в последовательнсти. Коррелирующий набор создается неявно в соответствии с Акривирующим Subscription выражением (Activation Subscription expression).

Есть несколько ограничений по построению Orchestration, работающих в этом режиме. Одно из главных заключается в том, что только один Receive shape разрешен в таком Orchestration.

Есть два больших преимущества в новом режиме:

  • Это значительно упрощает создание Orchestration, обеспечивающих Последовательную Доставку сообщений.
  • Это нивелирует проблему с Зомби. Теперь жизненный цикл экземпляра Orchestration более контролируем. Экземпляр удаляется (recycled) только тогда, когда в MessageBox нет сообщений, стоящих в очередь к этому экземпляру.

Заключение

Мы обсудили реализацию Последовательной Доставки сообщений в BizTalk Server и возможные пути по ее улучшению.

2 комментария

Filed under BizTalk

2 responses to “BizTalk: Последовательная доставка сообщений

  1. I think this is one of the most significant information for me.
    And i am happy reading your article. But want to commentary on few common issues, The website taste is ideal, the articles is truly great
    : D. Excellent task, cheers

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s