BizTalk: Synchronous pattern. Really?

Последнее время стало модно делать интеграцию в асинхронном стиле. Ничего не блокируется, а значит хорошо масштабируется.  И крайний случай асинхронного стиля – ESB, Enterprise Service Bus, когда все данные перемещаются асинхронно.

Круто.

А на другом конце спектра – point-to-point интеграция, точечная. По крайней мере, если вы спросите об этом архитектора, то ESB много лучше point-to-point. И одна из главных причин в том, что ESB – асинхронна по сути, а point-to-point обычно в видет request-response, синхронна. С тем, что ESB лучше point-to-point я не соглашусь, но разговор здсь не об этом.

Если посмотреть в Википедии, полазить по книжкам, то окажется, что точного понятия синхонности и асинхронности в отношении ИТ и обмена данными нет.

Классическое определиение синхронности мало что нам даст. Синхронность, это когда время в раздельных точках установлено одинаково. В одном месте 54 минуты, 44 секунды и 234234 мили-микро и т.д секунд и в другом в этот же момент времени часы покажут те же цифры.

В ИТ под синхронностью обычно понимается нечто вытекающее из классического понятия, но описываемого с позиций передачи данных между системами.

Будет пример, когда два процесса будут связаны по каналу, связь будет поддерживаться в неком сеансе, данные будут перемещаться в обоих направлениях и тому подобное, и эти процессы будут синхронными.

Будет пример, когда два процесса будут связываться через некий буфер, очередь, канал. Когда данные будут исходной системой передаваться в очередь, после чего эта система продолжит заниматься своими делами. Очередь передаст данные системе-получателю. Которая, может быть, отправит ответ исходной системе таким же образом, через очередь.

Как обмен данными происходит в BizTalk? Как реализуются синхронные и асинхронные процессы в BizTalk?

В качестве примера возьмем типичную задачу по интеграции двух систем, так называемый request-response. Одна система (А) запрашивает данные у другой системы (В). А посылает запрос в систему В, В обрабатывает данные и высылает результат обратно системе А.

На первый взгляд перед нами point-to-point интеграция, синхронный процесс. Так ведь?

А теперь подробнее.

BizTalk приемный порт (receive port) запускает процесс при появлении данных по адресу порта. Порт играет роль listener-а. Порт запускает отдельный message процесс под каждый запрос. Этот процесс обрабатывает запрос и записывает его в Почтовый Ящик (MessageBox) BizTalk.  Почтовый Ящик представляет из себя SQL Server базу данных, а с точки зрения системы по обработки сообщений он представляет из себя систему очередей. Почтовый Ящик – это сервер очередей сообщений. Send port (порт отправки) системы В является подписчиком для запросов из системы А. Запросы эти он получает из Почтового Ящика.  Порт получает новый запрос, после чего отправляет этот запрос в систему В и получает обратно ответ. Порт записывает ответ в Почтовый Ящик BizTalk. Приемный порт системы А является подписчиком для данного ответа. Он получает ответ из Почтового Ящика и отправляет его в систему А.

Таким образом данные два раза проходят через Почтовый Ящик. Сначала запрос, потом ответ.

Самое интересное в этом – очереди. Очереди по своей сути асинхронны.  Запрос и ответ не передаются в рамках одной сессии. Создаются от двух до четырех сессий: система А – приемный порт для запроса, порт отправки – система В для запроса, система В – порт отправки для ответа, приемный порт – система А для ответа. В зависимости от транспортного протокола сессии для запроса и ответа могут быть в рамках одной сессии, к примеру для HTTP протокола.

Любая передача сообщений через BizTalk асинхронна.

Архитектор, проектирующий интеграционную систему на базе BizTalk Server, должен понимать, что имеет дело с принципиально асинхронной системой.

В рассмотренном примере с точки зрения системы А передача данных, запрос и ответ, происходят в рамках одной сессии, передача выглядит синхронной. С точки зрения системы В передача данных тоже происходит в рамках одной сессии и также синхронно. На самом деле обе эти сессии замыкаются в рамках система – Почтовый Ящик.

Даже процессы, выглядящие на первый взгляд синхронными, в BizTalk Sever всегда реализуются на базе принципиально асинхронной системы, очереди сообщений – Почтового Ящика BizTalk.

Оставьте комментарий

Filed under BizTalk, Integration Architecture

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s