Отзыв на книгу "Шаблоны интеграции корпоративных приложений"

Прочитал книгу:

Хоп, Грегор, Вульф, Бобби. Шаблоны интеграции корпоративных приложений. : Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007. – 672 с.: ил.

Книга вышла в серии “A Martin Fowler Signature Book” и посвящена шаблонам интеграции корпоративных приложений.

В настоящее время для интеграции корпоративных приложений используются 4 техники:

1)      Передача файла (File Transfer).

2)      Общая база данных (Shared Database).

3)      Удаленный вызов процедуры (Remote Procedure Invocation).

4)      Обмен сообщениями (Messaging).

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

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

А. Специализация.

После появления приема (шаблона) начинают возникать его специализированные версии для особых случаев.

ПРИМЕР 1. Для обмена сообщениями между приложениями создаются каналы. Канал – это нечто, что позволяет передать сообщение от одной программы другой программе. Существуют и специальные типы каналов:

Название	Английское название	Страница	Назначение
Канал типа данных	Datatype Channel	139	Передача сообщений строго определенного типа.
Канал недопустимых сообщений	Invalid Message Channel	143	Канал, в который отправляются все сообщения, не несущие никакого смысла для получателя.
Канал не доставленных сообщений	Dead Letter Channel	147	Канал, в который помещаются все сообщения, которые по тем или иным причинам не удается доставить.

ПРИМЕР 2. Для коммуникации между приложениями по каналам используются сообщения. Появляются и специализированные виды сообщений.

Название	Английское название	Страница	Назначение
Сообщение-команда	Command Message	169	Послать приложению определенную команду.
Сообщение-документ	Document Message	171	Передать приложению данные документа.
Сообщение о событии	Event Message	174	Уведомить приложение о произошедшем событии.

ПРИМЕР 3. Для маршрутизации сообщений между приложениями используются маршрутизаторы. Существуют маршрутизаторы специализированных видов:

Название	Английское название	Страница	Назначение
Разветвитель	Splitter	274	Разбивает сообщение, если оно состоит из нескольких частей, и каждая часть требует специализированной обработки.
Агрегатор	Aggregator	283	Комбинирует содержимое разных, но связанных между собой сообщений.
Преобразователь порядка	Resequencer	297	Упорядочивает сообщения, если они были доставлены не в том порядке.

Б. Объединение специализированных приемов в пары или последовательности.

Специализированные приемы объединяются в последовательности. Сначала устойчивые сочетания составляют парные приемы (по принципу: функция + анти-функция).

ПРИМЕР 4. Специализированные сообщения могут быть объединены в последовательности:

Название	Английское название	Страница	Назначение
Запрос – ответ	Request – Reply	177	Переслать информацию о состоянии по запросу.
Событие – запрос – ответ		176	Уведомить о произошедшем событии. Переслать информацию о состоянии по запросу.

ПРИМЕР 5. Маршрутизаторы тоже могут объединяться в пары:

Название	Английское название	Страница	Назначение
Обработчик составного сообщения	Composed Message Processor	307	Разбивает сообщение на несколько частей, направляет каждое из полученных сообщений на необходимую обработку, а результаты обработки снова собирает в единое сообщение.
Рассылка – сборка	Scatter – Gather	310	Рассылает сообщение нескольким получателям, а затем – собирает ответы от них в единое сообщение.

Можно сделать вывод: с некоторого момента выгодно изучать не отдельные приемы или шаблоны, а их сочетания.

В. Надсистемные переходы.

При увеличении количества сущностей и их разнородности приходится изобретать контексты для их группировки.

ПРИМЕР 6. Для интеграции двух приложений при помощи обмена сообщениями достаточно канала «точка – точка» (Point-to-Point Channel, стр. 131).

Если сообщение должны получить несколько получателей, то можно использовать канал «публикация – подписка» (Publish – Subscribe Channel, стр. 134).

Если разные приложения выступают в роли как получателей, так и отправителей сообщений, и сообщение, посланное одним приложением, должно быть получено всеми остальными приложениями, то используют канал «шина сообщений» (Message Bus, стр. 162).

Если же надо объединить воедино не только разные приложения, но и разные системы обмена сообщениями, и сообщения должны переходить из одной системы в другую, то используют канал «мост обмена сообщениями» (Message Bridge, стр. 159).

ПРИМЕР 7. Если нужно объединить два приложения, которые принимают сообщения в разных форматах, то можно обойтись одним-двумя преобразователями сообщений: из одного формата в другой.

Если количество приложений велико, и каждое из них требует, чтобы сообщения соответствовали его формату, то выгоднее использовать шаблон «каноническая модель данных» (Canonical Data Model, стр. 367). Суть шаблона: все приложения обмениваются между собой сообщениями в каноническом формате. Если само приложение не поддерживает сообщение в каноническом формате, то на входе и выходе стоит преобразователь, который преобразует сообщение из канонического формата в формат приложения и наоборот.

Г. Выделение функциональных подсистем внутри системы при увеличении нагрузки.

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

Если в начале одна система выполняла три функции А, Б и В, но этого не было заметно, т.к. нагрузка на систему была небольшой, то при увеличении нагрузки для выполнения каждой функции формируется своя подсистема.

ПРИМЕР 8. Для маршрутизации сообщений между приложениями может быть использован шаблон «Маршрутизатор на основе содержимого» (Content-Based Router, стр. 247). Он анализирует содержимое поступившего сообщения и, в зависимости от результатов анализа, перенаправляет сообщение тому или иному получателю.

Если приложения-получатели могут меняться в зависимости от времени и могут меняться правила маршрутизации, то можно использовать типовое решение «Динамический маршрутизатор» (Dynamic Router, стр. 259). В этом случае, при подключении или удалении приложений-получателей изменяются и правила маршрутизации.

Таким образом, создаются предпосылки для отделения модуля правил маршрутизации от модуля маршрутизации.

Полностью же такое отделение происходит в типовом решении «Список получателей» (Recipient List, стр. 264). На вход маршрутизатор получает сообщений и список адресатов, которым он должен разослать сообщение. А сам список адресатов формируется каким-либо другим модулем.

ПРИМЕР 9. Похожая закономерность наблюдается и в тех случаях, когда одно и то же сообщение нужно провести через ряд последовательных стадий обработки. В самом простейшем случае этапы объединяются в последовательности, а маршрутизатор, получив сообщение, анализирует его и пренаправляет соответствующей последовательности.

Например, для обработки некоторого сообщения могут использоваться две последовательности:

Последовательность-1: Этап А -> Этап Б -> Этап В.

Последовательность-2: Этап А -> Этап В.

Во второй последовательности отсутствует промежуточный этап Б.

Недостатков у такого решения несколько:

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

o       Во-вторых, последовательности этапов нельзя формировать динамически. Все последовательности жестко заданы заранее.

Для устранения недостатков можно использовать типовое решение «Карта маршрутизации» (Routing Slip, стр. 314). Это решение напоминает другое типовое решение – «Список получателей». Только вместо списка получателей, которым маршрутизатор должен разослать сообщение, вместе с сообщением поступает карта маршрутизации – последовательность этапов обработки, через которые должно пройти исходное сообщение. Подобную карту составляет какой-то другой компонент.

Шаблон «Карта маршрутизации» не рассматривает, как должна происходить маршрутизация после прохождения сообщением определенного этапа. В качестве решения каждый этап обработки может обладать своим собственным маршрутизатором, а все этапы могут быть связаны друг с другом. Сначала сообщение поступает на вход системы. В соответствии с картой маршрутизации система передает сообщение на первый этап. А за дальнейшую маршрутизацию сообщения после прохождения первого этапа отвечает маршрутизатор этого этапа.

Ясно, что такая схема неэффективна при большом количестве всевозможных этапов. Типовое решение «Диспетчер процессов» (Process Manager, стр. 325) связывает все этапы обработки с одним маршрутизатором. После прохождения определенного этапа сообщение пересылается назад к маршрутизатору, который, в соответствии с картой, перенаправляет его другому этапу. Таким образом, разделяются функции маршрутизации и обработки.

Правда единственный маршрутизатор рискует не справиться с нагрузкой и превратиться в узкое звено. Но при желании его функции можно передать двум или трем параллельно работающим маршрутизаторам. Важно тут другое – разделение функций и распределение их между разными компонентами.

Отзыв написан в 2007-ом году.