Inf_comp_sys

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

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

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

Этап А

Доставить

сообщение согласно карте маршрутизации

Диаграмма 44

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

171

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

16.5.14 Диспетчер процессов

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

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

172

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

Диспетчер процессов организует движение сообщений по принципу звезды (Диаграмма 45). Вначале входящее сообщение выполняет инициализацию диспетчера процессов. Основываясь на встроенных правилах, диспетчер процессов отправляет сообщение на первый этап обработки (этап А). Когда компонент А заканчивает обработку сообщения он возвращает сообщение с ответом диспетчеру процессов. Диспетчер определяет, какой этап обработки должен быть выполнен следующим, и отправляет сообщение (2) соответствующему компоненту (компоненту Б). Слабой стороной такого центрального элемента является опасность превращения диспетчера процессов в "узкое место".

1

Этап А

2

Этап Б

Инициализирующее

сообщение

Этап В

3

Диаграмма 45

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

16.5.15 Брокер сообщений

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

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

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

173

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

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

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

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

Получатель

1

Диаграмма 46

174

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

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

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

16.6.1 Устранение зависимостей

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

16.6.2 Управление метаданными

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

176

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

На диаграмме 47 изображен пример интеграции двух приложений, которые должны обмениваться сведениями о клиентах. В каждой из систем информация о клиенте организована по-разному. Например, в программе А имя и фамилия клиента хранятся в двух отдельных полях, а в программе Б эти же данные занимают одно поле. Кроме того, программа А работает с индексом местности, в которой проживает клиент, а программа Б - с аббревиатурой штата. Сообщения, передаваемые программой А программе Б, должны подвергнуться преобразованию, чтобы программа Б получила данные в понятном для себя виде. Реализация такого преобразования значительно упрощается, если адаптеры канала смогут извлекать и метаданные, например данные, описывающие формат сообщения. Извлеченные метаданные могут быть загружены в репозиторий, что существенно упростит настройку и проверку правильности транслятора сообщений. Метаданные можно хранить в различных форматах. Для хранения метаданных ХМL-сообщений применяется ХSD. Другие ЕАI-средства работают с закрытыми форматами метаданных, но позволяют администраторам импортировать и экспортировать метаданные в ряд других форматов.

177

16.6.3 Оболочка конверта

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

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

178

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

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

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

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

Диаграмма 48

Процесс упаковки сообщения в конверт с последующей распаковкой состоит из пяти шагов.

Исходное приложение публикует сообщение в необработанном виде. Формат такого сообщения определяется характером приложения и не соответствует требованиям инфраструктуры обмена сообщениями.

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

179

Система обмена сообщениями передает упакованное сообщение в пункт назначения.

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

Сообщение "в чистом виде" доставляется получателю.

16.6.4 Расширитель содержимого

Часто получателю сообщения требует больше информации, чем может предоставить исходная система. Например, система-отправитель работает с идентификаторами клиентов, а системе-получателю требуются полное имя и адрес клиента.

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

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

Расширитель

содержимого

Источник

данных

Диаграмма 49

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

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

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

180