Inf_comp_sys

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

16.5.7.1Надежность

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

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

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

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

16.5.7.2Динамический список получателей

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

161

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

16.5.7.3Эффективность с точки зрения сети

Наиболее эффективный подход зависит от реализации инфраструктуры обмена сообщениями. В общем случае чем больше получателей у сообщения, тем больший объем сетевого трафика оно создает. Однако, некоторые системы публикации-подписки основаны на многоадресной IР-рассылке и могут направлять сообщения нескольким получателям в рамках одной сетевой передачи. Действие многоадресной IР-рассылки основано на свойствах топологии "шина", применяемой в сетях Ethernet. Когда пакет IР отправляется по сети, его получают все сетевые адаптеры, находящиеся в том же сегменте, что и отправитель. Сетевой адаптер проверяет, кому предназначается пакет, и игнорирует его в случае, если адрес назначения пакета не совпадает с IРадресом этого адаптера. При многоадресной маршрутизации все получатели, входящие в заданную группу многоадресной рассылки, могут считывать пакет из шины. В результате один и тот же пакет может быть получен несколькими адаптерами, которые затем передают данные соответствующим приложениям. Такой подход эффективен для локальных сетей с топологией "шина", но не подходит для Интернета, где требуются соединения ТСР/IР типа "точка-точка". Из этого можно сделать вывод, что чем дальше находятся получатели, тем выгоднее использовать список рассылки вместо канала "публикация-подписка".

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

16.5.8 Разветвитель

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

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

162

обработки или потери данных. Также, решение должно эффективно использовать сетевые ресурсы.

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

Чтобы разбить сложное сообщение на несколько небольших сообщений необходимо использовать разветвитель. Каждое из них будет содержать данные, касающиеся отдельного элемента исходного сообщения (Диаграмма 39).

Диаграмма 39

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

16.5.8.1Итеративные разветвители

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

16.5.8.2Статические разветвители

Использование разветвителя не ограничивается выделением элементов заказа. Большое сообщение может быть разбито на более мелкие просто для упрощения обработки. Например, ряд В2В-стандартов, описывающих обмен

163

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

16.5.9 Агрегатор

Разветвитель удобно применять, чтобы разбить одно сообщение на несколько более мелких, каждое из которых должно обрабатываться отдельно. Список получателей или канал "публикация-подписка" незаменим, когда сообщение с запросом необходимо одновременно направить ряду получателей, чтобы затем иметь возможность выбрать один из нескольких ответов. В большинстве сценариев такого рода дальнейшие действия зависят от успешной обработки вспомогательных сообщений.

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

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

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

164

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

Для того, чтобы собирать и сохранять отдельные сообщения для сбора полного набора связанных между собой сообщений необходимо использовать агрегатор (Диаграмма 40).

Диаграмма 40

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

16.5.10 Преобразователь порядка

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

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

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

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

165

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

Для сборки и упорядочивания сообщения с тем, чтобы их можно было опубликовать в исходящем канале необходимо использовать преобразователь порядка (Диаграмма 41).

Диаграмма 41

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

16.5.10.1Порядковый номер

Для корректного функционирования преобразователя порядка у каждого сообщения должен быть порядковый номер, или идентификатор позиции. Порядковый номер отличается от идентификатора сообщения или идентификатора корреляции. Идентификатор сообщения - это специальный атрибут, который уникальным образом идентифицирует каждое сообщение. Однако в большинстве случаев идентификаторы невозможно сравнивать: это случайные значения, часто даже не числовые. Идентификаторы корреляции предназначены для сопоставления полученных ответов с исходными запросами. Единственным требованием к идентификаторам корреляции является уникальность; они не должны быть числовыми или образовывать

166

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

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

16.5.11 Обработчик составного сообщения

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

Для решения данной задачи необходимо использовать несколько шаблонов проектирования. Разветвитель может разбить сообщение на несколько отдельных частей. Маршрутизатор на основе содержимого может распределить полученные сообщения по требуемым этапам обработки в зависимости от типа или содержимого сообщения. Архитектурный стиль каналы и фильтры позволяет связать воедино оба указанных шаблона, чтобы каждый из элементов составного сообщения направлялся на соответствующие этапы обработки. Агрегатор, чтобы собрать ответы на запросы, которые были отправлены на обработку в разные системы. Каждый обрабатывающий компонент отправляет агрегатору ответ, в котором сообщает результаты обработки. Агрегатор собирает отдельные ответы и обрабатывает их с помощью заранее заданного алгоритма. (Диаграмма 42).

167

Система А

Диаграмма 42

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

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

16.5.12 Рассылка-сборка

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

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

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

Необходимо также координировать дальнейшее продвижение сообщений. Самое простое решение этой проблемы состоит в том, чтобы каждый получатель запроса публиковал свой ответ в канале, а последующие

168

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

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

Шаблон рассылка-сборка направляет сообщение с запросом нескольким получателям. После этого он использует агрегатор, чтобы собрать ответы получателей и объединить их в одно итоговое сообщение с ответом (Диаграмма

43).

Поставщик А

Широковещание Поставщик Б Запрос цены

Поставщик В

Цена

Лучшая цена

Агрегатор

Диаграмма 43

Существует два варианта рассылки-сборки, в которых применяются различные механизмы отправки сообщения с запросом предполагаемым получателям.

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

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

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

169

всего, будет добавлен обратный адрес, чтобы все ответы можно было собирать в один канал. Рассылка-сборка, как и обработчик составного сообщения, агрегирует ответы в соответствии с заранее заданными бизнес-правилами.

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

16.5.13 Карта маршрутизации

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

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

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

Ключевые требования к решению проблемы можно сформулировать в виде четырех пунктов.

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

Эффективное использование ресурсов. В решении не должно применяться слишком много каналов, маршрутизаторов и других ресурсов.

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

170