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

Здесь английская версия статьи: http://geekswithblogs.net/LeonidGaneline/archive/2006/12/18/101541.aspx

———————————-
Когда я начал работать с BizTalk, я начал строить в голове разные модели того, что происходит с сообщениями внутри BizTalk. С каждой новой итерацией получалась другая модель.
[Далее я не перевожу на русский язык основные термины BizTalk-а: Receive Location, Send Port, Orchestration, MessageBox и т.д., иначе получится полная мешанина.]
Все началось с традиционной модели:

Назовем эту модель «Принять — Отправить».
Речь здесь идет об отправлении и приемке сообщений.
Выглядит, как будто Receive Locations – это приемники сообщений, Send Ports – передатчики сообщений, а Orchestrations являются одновременно приемниками и передатчиками. Правильно?
Не совсем так. Все объекты являются как приемниками, так и передатчиками.
Receive Locations получают сообщения из «внешнего мира» и потом отправляют их в Message Box.
Send Ports получают сообщения из Message Box и передают их дальше, во «Внешний мир».
Orchestrations получают сообщения из Message Box и передают их дальше. Куда? Опять в Message Box.
Message Box получает сообщения от Receive Locations или от Orchestrations и передает их в Send Ports или снова в Orchestrations.
В BizTalk Help есть описание другой модели, Издатель-Подписчик (Publisher-Subscriber). Но большая часть внимания в Help уделена именно модели Принять-Отправить.
Термины отправить и принять продолжали смущать меня.
Для иллюстрации неоднозначности терминов посмотрим на цитату из книги «Pro BizTalk 2006», написанной George Dunphy и Ahmed Metwally, страница 119:
« … The left side shows the sender configuration, which consists of a static one-way send port to send the business document or message and a static one-way receive port to receive BizTalk Framework 2.0 delivery receipts. The right side shows the receiver configuration, which contains a static one-way receive port to receive the message and a dynamic one-way send port that… »
В переводе:
« …Левая часть показывает передающую конфигурацию, которая состоит из статического одностороннего передающего порта и статического одностороннего принимающего порта. Эта конфигурация получает BizTalk Framework 2.0 подтверждении доставки. Правая часть показывает принимающую конфигурацию, которая состоит из статического одностороннего принимающего порта и динамического одностороннего передающего порта…»
(Я выделил смущающие меня термины.)
Передающая конфигурация и предает, и принимает сообщения? Так же, как и принимающая конфигурация?
Хорошо, давайте обсудим эту неоднозначность. Термины передать и принять означают… Хмммм, они означают одно и то же?
Мы передаем сообщение? Да. И ОДНОВРЕМЕННО мы принимаем сообщение.
Эти термины имеют смысл ТОЛЬКО, если они используются ВМЕСТЕ с субъектом или объектом операции.
Сообщение передается? Звучит неоднозначно. Передатчик отправляет сообщение в приемник.
Сообщение принимается? Неоднозначно. Приемник принимает сообщение от передатчика.
Попробуем использовать другие термины, такие, как публиковать и подписываться.
Эти термины в контексте BizTalk всегда означают «относительно MessageBox».
Повторюсь, термины передать и принять неоднозначны без указания объекта и субъекта.
После того, как я сделал изменения, получилась вторая версия модели:

Здесь я выдвинул термины Subscriber и Publisher на первое место модели.
Эта модель «Message Box — центрированная», 🙂
Publishers передают сообщения в Message Box. Subscribers принимают сообщения из Message Box.
Все действия происходят вокруг Message Box.
Publishers передают сообщения с определенным типом в Message Box. Тип сообщения в BizTalk определяется, как объединение значений namespace и имя корневого узла (namespace + root_node). Речь идет, конечно, о сообщении в формате XML, так как все сообщения внутри BizTalk имеют формат XML. Subscribers принимают из Message Box только те сообщения, которые проходят через фильтр конкретной подписки (Filter expression).
В этой модели Receive Locations и Send Shapes в Orchestrations размещаются в группе Publishers, а Send Ports и Receive Shapes размещаются в группе Subscribers.
Давайте попробуем встроить в эту модель термин Binding.
Я получил такую модель.

Binding = неявная подписка
[the Binding = the Implicit Subscription]
Подписка для Binding создается за сценой. В большинстве случаев Publishers ID используется как Filter expression.
Термин Binding используется здесь для описания связи между Orchestration и Port.
Насколько я понимаю, этот термин был создан для упрощения модели, для автоматизации работы с созданием наиболее простой и наиболее часто используемой операции, когда сообщения передаются из одной четко определенной точки в другую точно определенную точку. Binding создает 1-1 связь, когда один Publisher должен передать сообщения одному Subscriber. Binding делает шаг в сторону от «чистой» модели Publisher-Subscriber (издатель-подписчик), которая заложена в основе BizTalk, и реализует один из часто используемых шаблонов передачи сообщений (Direct Link).
Publishers и Subscribers в чистой модели Publisher-Subscriber не знают ничего друг о друге и не должны знать. Publishers отправляют сообщения в Message Box, а Subscribers извлекают сообщения из Message Box, опираясь на параметры подписки.
Binding делает модель более сложной. Binding упрощает выполнение одной конкретной операции, но при этом усложняет модель.
Чистая Publisher-Subscriber модель в BizTalk доступна с помощью так называемого Direct port.
Ниже очередная версия модели:

Здесь я изобразил Orchestration из двух частей. В предыдущей модели Send и Receive Shapes были в одной Orchestration.
Я изобразил Shapes и Port/Locations одинакового размера. Интуитивно Orchestrations не должны быть «больше», чем Ports.
Добавлен «Внешний мир» («Outer World»).
Теперь это Publisher-Subscriber model.

Выводы:

  •  Модель «Принять – Передать» усложняет восприятие архитектуры BizTalk. Не используйте термины отправить и принять (Receive и Send) для описания движения сообщений. Лучше используйте термины издать и подписаться (Publish и Subscribe).
  •  Подходите критически к BizTalk Help, так как там термины receive и send используются бессистемно.
  •  Binding желательно использовать на втором уровне погружения в BizTalk. Этот термин усложняет понимание, он маскирует Publisher-Subscriber модель. Описание операций с сообщениями без использования этого термина облегчает жизнь.
Реклама

1 комментарий

Filed under BizTalk

One response to “Архитектура BizTalk

  1. Да уж, это на самом деле непросто. 🙂

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

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

Логотип WordPress.com

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

Google+ photo

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

Фотография Twitter

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

Фотография Facebook

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

Connecting to %s