Создание приложений для доступа к инфраструктуре WebSphere MQ

4.3. Сообщения WebSphere MQ

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

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

4.3.1. Дескриптор сообщения

Каждое сообщение в инфраструктуре WebSphere MQ имеет связанный с ним дескриптор (message descriptor).

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

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

Примерами метаданных, которые мы обсудим в этой главе, являются:

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

4.3.2. Преобразование данных

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

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

WebSphere MQ можно настроить для выполнения такого преобразования двумя способами.

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

4.3.3. Форматы сообщений

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

Формат сообщения определяет один тип данных.

Часто сообщения содержат данные только в символьном представлении, так как оно может служить для записи и цифр, и букв. К примеру, для обеспечения единой структуры передаваемых сообщений приложения-отправители и приложения-получатели могут пользоваться языком XML (Extensible Markup Language). XML-сообщения представляют все содержащиеся в них данные в виде символов, так что WebSphere MQ может произвести конвертацию данных всего подобного сообщения.

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

4.3.4. Сборка сообщений из их фрагментов

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

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

Вкратце типы фрагментов сведены в приведенный далее перечень:

• Фрагмент, который WebSphere MQ может рассматривать как содержащий единый тип данных. Данные, которые WebSphere MQ может воспринимать в качестве однотипных, – это:
  • двоичные данные, которые WebSphere MQ не конвертирует;
  • символьные данные, конвертацию которых WebSphere MQ может произвести.
• Структура WebSphere MQ: структуры такого рода могут содержать данные многих различных типов, а ряд структур – и дополнительные метаданные сообщения. Структуры могут автоматически добавляться и удаляться из сообщений самим WebSphere MQ при прохождении инфраструктуры.

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

  Примеры структур данного рода следующие.

  • Заголовок транспортной очереди и очереди недоставленных сообщений: Автоматически добавляются к сообщению менеджером очередей в ситуациях, описанных далее в этой книге. Обычно приложения не добавляют к сообщениям сами эти структуры, однако знать о возможности добавления к сообщению данных структур полезно при просмотре сообщений в очереди менеджера очередей.
  • Первый и второй заголовки правил и форматирования. Могут использоваться приложениями для описания содержимого сообщений с данными множества разных типов, например, с комбинацией символьных и числовых данных. Сборка ряда фрагментов одного сообщения с использованием этих структур может оказаться полезной для проведения дифференцированной конвертации данных из различных фрагментов.
  Примечание Сообщения, помещенные в инфраструктуру WebSphere MQ стандартизованными API, такими как JMS (Java Message Service), нередко содержат автоматически пристыкованные к ним заголовки правил и форматирования, в которых содержатся метаданные, необходимые стандартизованным интерфейсам.
• Команда WebSphere MQ. Отдельные сообщения адресуются компонентам WebSphere MQ, заставляя их выполнять определенные действия. Примерами упомянутых компонентов являются брокер публикации-подписки, а также командный сервер WebSphere MQ, обсуждаемые далее в этой книге. Структуру сообщений, которые содержат эти команды, WebSphere MQ определяет самостоятельно.
  Примечание Использование стандартизованных интерфейсов, например JMS, для приема и передачи сообщений по принципу публикации-подписки может сделать необязательными формирование и передачу команд брокеру публикации-подписки в составе WebSphere MQ.

4.4. Взаимодействие с инфраструктурой WebSphere MQ

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

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

Кроме того, используя клиентское (client) подключение по сети, приложения могут соединяться с менеджером на удаленной машине. Работа соединения как клиента накладывает свой отпечаток на его скорость, а удаленный менеджер очередей должен быть доступен для успешного подключения. Вместе с тем установку сервера на машину, где расположен клиент, производить не потребуется.

4.4.1. Клиентские продукты WebSphere MQ

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

4.4.2. Основные возможности приложения WebSphere MQ

Приведенный далее перечень вкратце описывает основные возможности, которые предоставляются приложениям, подключенным к инфраструктуре WebSphere MQ через отдельный менеджер.

• Приложение может извлекать сообщения из очередей под управлением данного менеджера для обработки и реализации службы с интерфейсом к очереди, выполненным по принципу "запрос – ответ" или "отправил – забыл".
• С учетом характеристик очереди менеджера очередей, к которому произошло подключение, приложение может получить в инфраструктуре уникальный объект. Он предъявляется другим приложениям, давая им возможность посылать сообщения данному. При межточечном обмене в WebSphere MQ он называется очередью ответа ( reply-to queue ); другое его название – очередь отклика ( response queue ).

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

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

  Инфраструктуру WebSphere MQ можно настроить так, чтобы маршрутизация сообщений учитывала лишь названия очередей. Это рекомендуется делать при отправке сообщений службам, что оставляет возможность перенастроить инфраструктуру без ущерба для интерфейса к службам-получателям сообщений.

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

  И в первом, и во втором случае менеджер очередей, к которому подключено приложение, должен знать, как направить сообщение в очередь назначения. Решение на этот счет в процессе разрешения названия очереди (queue name resolution) принимает каждый менеджер на пути к месту назначения сообщения, а значит, он должен знать лишь следующий шаг маршрута доставки по назначению.

  Информацию о маршрутах к очередям и менеджерам, которую хранят все менеджеры очередей сообщений, можно сконфигурировать при помощи определенных на данном менеджере объектов очередей (queue objects) WebSphere MQ. Кластеры менеджеров дают возможность автоматически узнавать об альтернативных маршрутах к очередям и менеджерам в составе инфраструктуры, а также производить балансировку нагрузки между несколькими очередями кластера с одним именем.

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

При непосредственном использовании публикации и подписки в WebSphere MQ реализованный в инфраструктуре брокер публикации-подписки принимает команды по интерфейсу "запрос – ответ". Интерфейс позволяет зарегистрировать приложение в роли подписчика по некоторой теме, публиковать по ней сообщения или посылать брокеру команды прочего содержания.

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

Подробнее о публикации и подписке в WebSphere MQ и расширении возможностей публикации и подписки в инфраструктуре WebSphere MQ см. "раздел 4.7" "Обмен по принципу публикации-подписки".