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

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

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


Назовем эту модель «Принять — Передать».
Ясно, что речь здесь идет об отправлении и приемке сообщений.
Выглядит, как будто 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 уделена именно модели Принять-Передать.
Термины передать и принять продолжали смущать меня.
Для иллюстрации неоднозначности терминов принять и передать в контексте BizTalk, посмотрим на цитату из книги «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. Выход / Изменить )

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s