Inf_comp_sys

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

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

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

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

16.6.5 Фильтр содержимого

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

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

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

181

Фильтр

содержимого

Диаграмма 50

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

16.6.6 Квитанция

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

иобработки. Наличие дополнительных данных замедляет обработку сообщения

изатрудняет отладку, поэтому от них следует временно избавиться.

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

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

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

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

182

Хранилище

данных

Диаграмма 51

Действие квитанции можно разбить на пять этапов. Прибывает сообщение с данными.

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

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

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

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

16.7Конечные точки обмена сообщениями

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

16.7.1 Шаблоны отправки и получения сообщений

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

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

183

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

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

16.7.2 Шаблоны потребителей сообщений

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

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

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

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

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

184

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

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

16.7.3 Шлюз обмена сообщениями

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

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

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

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

185

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

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

16.7.4 Транзакционный клиент

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

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

Конечные тонки сообщения, занимающиеся отправкой и получением сообщений, по своей природе являются транзакционными. Метод отправки,

186

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

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

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

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

Координация «сообщение - база данных». Комбинация отправки или получения сообщения с обновлением базы данных.

Координация «сообщение - рабочий поток». Использование пары сообщений запрос-ответ для выполнения единицы работы и применения транзакций для

получения гарантии, что единица работы не будет открыта, пока не будет отослан запрос, и не будет закрыта, пока не будет получен ответ.

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

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

сдругими транзакциями этой же или любой другой системы.

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

187

16.7.5 Опрашивающий потребитель

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

Главное преимущество опроса состоит в том, что потребитель может запросить из канала следующее сообщение только тогда, когда готов это сделать. Таким образом, потребитель получает сообщения с удобной для себя интенсивностью (Диаграмма 53).

Отправитель Сообщение Опрашивающий потребитель

Получатель

Диаграмма 53

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

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

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

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

188

16.7.6 Событийно управляемый потребитель

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

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

Диаграмма 54

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

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

16.7.7 Конкурирующие потребители

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

189

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

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

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

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

Отправитель Сообщения

Потребитель

Получатель

Диаграмма 55

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

190