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

Разбить на страницы

Показывать лекцию целиком

Лекция посвящена следующим вопросам:

Кроссплатформенная поддержка

Интерфейсы прикладного программирования (API)

Сообщения WebSphere MQ

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

Транзакции и единицы работы

Межточечный обмен сообщениями

Обмен по принципу публикации-подписки

4.1. Кроссплатформенная поддержка

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

Информацию о платформах, которые поддерживают менеджеры очередей в продукции IBM, см. на Web-странице по адресу: http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html.

Для каждой платформы, которая поддерживает работу WebSphere MQ, эта страница содержит особую спецификацию окружения (SOE – statement of environment) с подробным описанием уровней поддержки каждого программного компонента, с которым может взаимодействовать WebSphere MQ, а также необходимые для WebSphere MQ сведения о сопровождении компонентов. На ряде платформ версия WebSphere MQ, которую поддерживает платформа, может не являться последней.

Дополнительные платформы, которые не включены в список и не пользуются поддержкой корпорации IBM, могут поддерживать компании из числа партнеров IBM (IBM Business Partner).

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

4.2. Интерфейсы прикладного программирования (API)

Для подключения приложений к менеджерам очередей и взаимодействия с инфраструктурой WebSphere MQ, частью которой и является менеджер, необходим интерфейс прикладного программирования (API – application programming interface).

4.2.1. Интерфейс очередей сообщений (MQI)

Основным API-интерфейсом WebSphere MQ является интерфейс очередей сообщений (MQI – message queue interface).

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

Кроме того, MQI описывает все структуры, константы и базовые типы данных, необходимые в целях взаимодействия с WebSphere MQ. При разработке приложений с использованием MQI необходимо явно манипулировать этими типами и структурами.

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

COBOL

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

4.2.2. API-интерфейсы на базе объектной модели WebSphere MQ

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

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

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

WebSphere MQ предоставляет следующий набор объектно-ориентированных API-интерфейсов.

WebSphere MQ C++.

WebSphere MQ C++ служит API-интерфейсом для C++, соответствующим объектной модели WebSphere MQ. При создании приложений, обращающихся к WebSphere MQ на языке C++, программист может пользоваться как объектно-ориентированным API, так и прямым доступом к операционной системе и аппаратным возможностям, прибегая, где это необходимо, к функциям языка C. Подробнее об API-интерфейсе для C++ читайте в руководстве WebSphere MQ Using C++, SC34-6592.

WebSphere MQ base Java API.

WebSphere MQ base Java API является API-интерфейсом к базовому диалекту языка Java, соответствующим объектной модели WebSphere MQ. При создании Java-приложений для доступа к WebSphere MQ программист может использовать преимущества переноса приложения между платформами, который обеспечивает язык Java. Функциональность платформы Java может упростить и другие аспекты написания приложений. Подробнее о Java API читайте в руководстве WebSphere MQ Using Java, SC34-6591.

Примечание. Альтернативный интерфейс для языка Java описан в разделе 4.2.3 "Стандартизованные API-интерфейсы для WebSphere MQ".

Классы WebSphere MQ для .NET:

Классы WebSphere MQ для .NET играют роль отвечающего объектной модели WebSphere MQ API-интерфейса для окружения .NET. При помощи классов WebSphere MQ для .NET приложения Microsoft Windows могут разрабатываться на множестве языков программирования. Подробнее о .NET и классах WebSphere MQ читайте в руководстве WebSphere MQ Using .Net, GC34-6605.

Примечание. Альтернативный интерфейс для окружения .NET описан в разделе 4.2.3 "Стандартизованные API-интерфейсы для WebSphere MQ".

COM-интерфейс WebSphere MQ.

COM-интерфейс WebSphere MQ содержит ряд компонентов Microsoft ActiveX $$\text{\textregistered}$$, именуемых WebSphere MQ Automation Classes for ActiveX (MQAX). Компоненты MQAX соответствуют требованиям, традиционно предъявляемым к ActiveX-компонентам, и объектной модели WebSphere MQ. Подробнее о модели компонентных объектов (COM – Component Object Model) и MQAX читайте в руководстве WebSphere MQ for Windows V6.0, Using the Component Object Model Interface, SC34-6594.

4.2.3. Стандартизованные API-интерфейсы для WebSphere MQ

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

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

Доступ ко всему спектру функций инфраструктуры WebSphere MQ может требовать применения собственного API-интерфейса WebSphere MQ.

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

Java Message Service (JMS):

JMS – часть стандарта Java 2 Platform Enterprise Edition (J2EE), которая инкапсулирует как модель межточечного обмена, так и модель обмена сообщениями по принципу публикации-подписки. По сути, приложения, созданные на Java с JMS-интерфейсом, могут не зависеть от брокера, предоставляющего возможности публикации и подписки в WebSphere MQ. Это дает свою гибкость и позволяет обновлять брокер публикации-подписки WebSphere MQ без дорогостоящей переработки созданных приложений.

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

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

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

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

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

Встроенная JMS-служба, поставляемая с WebSphere Application Server V5, основана на WebSphere MQ V5.3. WebSphere Application Server V6 содержит новый компонент-поставщик службы обмена сообщениями по технологии JMS – WebSphere Platform Messaging. Поставщиком JMS для WebSphere Application Server V6 после соответствующей настройки может стать WebSphere MQ. Инфраструктура WebSphere Platform Messaging может соединяться с инфраструктурой WebSphere MQ. Реализуя новое приложение на языке Java и выполняя межточечный обмен либо обмен по принципу публикации-подписки, продумайте возможность взаимодействия с WebSphere MQ при помощи JMS.

Язык Java, JMS, спецификации J2EE и WebSphere Application Server являются важными темами, представляющими самостоятельный интерес.

IBM Message Service Client (XMS).

XMS – интерфейс обмена сообщениями для языков C, C++ и .NET-окружения. Подход XMS-интерфейса к приему и отправлению сообщений очень близок к подходу JMS API, а значит, и к преимуществам промышленной стандартизации, характерным для JMS.

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

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

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

На сегодняшний день средства для упрощения разработки приложений с применением XMS-интерфейса и обеспечения возможности отправки и получения сообщений подобными приложениями в инфраструктуре очередей сообщений WebSphere MQ находятся в пакете SupportPac IA94. Подробнее об этом см. по адресу: http://www.ibm.com/support/docview.wss?rs=171uid=swg24007092loc=en_UScs=utf-8lang=en

Примечание. В настоящее время SupportPac IA94 относится к категории 2 (Category 2), то есть его поддержка по каналам обслуживания продукции IBM недоступна. Подробности приведены на Web-сайте.

Реализуя новое приложение на C, C++ или в окружении .NET и выполняя межточечный обмен либо обмен по принципу публикации-подписки, продумайте возможность взаимодействия с WebSphere MQ при помощи XMS.

4.2.4. Индивидуальные адаптеры

Если WebSphere MQ не имеет интерфейса для конкретного языка программирования или программного компонента инфраструктуры, который необходим приложению, для него может быть создан индивидуальный адаптер (custom adapter).

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

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

Примером подобного адаптера является реализованная в пакете SupportPac MA89 поддержка языка Perl для MQSeries $$\text{\textregistered}$$. Этот индивидуальный адаптер служит интерфейсом между WebSphere MQ и языком Perl. Подробнее о SupportPac MA89 см. по адресу: http://www.ibm.com/support/docview.wss?rs=171uid=swg24000208loc=en_UScs=utf-8lang=en

Примечание SupportPac MA89 имеет 4-ю категорию сервиса (Category 4). Его поставку осуществляет не IBM, а сторонний производитель. Подробности приведены на Web-сайте.

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.

Примечание Некоторые клиентские продукты WebSphere MQ доступны как пакеты поддержки SupportPac, некоторые поставляются на дистрибутивном носителе для установки 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 "Обмен по принципу публикации-подписки".

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

4.5. Транзакции и единицы работы

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

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

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

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

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

Это действие называется извлечением (изъятием) сообщения из очереди или операцией get.

4.5.1. Локальные единицы работы

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

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

4.5.2. Точка синхронизации

Локальные единицы работы автоматически создаются при первом выполнении приложением операций put или get. Условием этого является требование к WebSphere MQ осуществить данное действие под управлением точки синхронизации ( syncpoint ).

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

4.5.3. Фиксация и отмена

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

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

Приложение отменяет ( back out ) единицу работы. Значит, все действия данной единицы работы аннулируются, каждое сообщение возвращается в очередь, из которой было извлечено в этой единице работы операцией get, и удаляется из очереди, в которую было помещено в этой единице работы операцией put.

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

4.5.4. Незафиксированные сообщения

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

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

В результате, если то же самое приложение повторно попытается произвести извлечение ( get ) в следующей единице работы, оно вполне может извлечь то же самое сообщение.

Сообщения, которые были помещены в очередь или изъяты из нее в пределах единицы работы, которая еще не зафиксирована и не отменена, называют незафиксированными (uncommitted).

Одновременно в каждом из подключений приложения к менеджеру может осуществляться лишь одна единица работы. Однако в разных потоках приложение может поддерживать несколько подключений. Поток – это средство, предоставляемое операционной системой или виртуальной машиной Java (JVM™ – Java Virtual Machine) для обеспечения возможности выполнять множество действий в одном приложении параллельно.

4.5.5. Глобальные единицы работы

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

Типичным набором действий, которые может произвести служба внутри системы, является:

изъять из очереди сообщение-запрос;

по его данным осуществить запросы к базе данных и ее обновления;

отослать сообщения другим службам внутри системы для дополнительного обслуживания запроса;

отослать ответ приложению, направившему запрос.

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

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

4.5.6. Координация глобальных единиц работы

Транзакция, управляющая глобальной единицей работы, координируется менеджером транзакций (transaction manager), который должен иметь возможность общаться со всеми участниками данной единицы работы. Участники глобальной единицы работы носят название менеджеров ресурсов (resource manager). В предшествующем примере к занятым в глобальной единице работы менеджерам ресурсов относились WebSphere MQ и база данных.

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

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

WebSphere MQ также может выступать в роли менеджера ресурсов глобальной единицы работы, координируемой внешним менеджером транзакций. Примерами внешних менеджеров транзакций являются IBM CICS$$\text{\textregistered}$$ , TXSeries $$\text{\textregistered}$$ и WebSphere Application Server.

Информацию о настройке WebSphere MQ как менеджера транзакций или менеджера ресурсов в глобальных единицах работы читайте в лекции 9 "Configuring WebSphere MQ" руководства WebSphere MQ System Administration Guide, SC34-6584.

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

4.5.7. Двухфазная фиксация

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

Двухфазная фиксация состоит из двух следующих шагов.

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

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

4.5.8. Спецификация XA

Спецификация XA опубликована организацией Open Group и описывает взаимодействия между менеджером транзакций и менеджером ресурсов. Ей отвечает и WebSphere MQ. Узнать подробнее о спецификации XA или загрузить ее текст можно на Web-странице по адресу: http://www.opengroup.org/bookstore/catalog/c193.htm

4.5.9. Расширенный транзакционный клиент

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

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

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

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

Примечание Данный продукт поставляется на условиях, отличных от принятых для клиентской инсталляции WebSphere MQ.

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

4.5.10. Отказоустойчивость и обработка ошибок

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

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

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

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

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

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

Примером такого рода процесса является виртуальная машина языка Java (JVM) на сервере приложений J2EE. Если сервер выявит сбой в выполняемом приложении и закроет его, при том что приложение работало как Java-поток на виртуальной машине, WebSphere MQ не обнаружит завершения потока до окончания работы JVM в целом. Впрочем, серверы приложений J2EE имеют поддержку менеджмента транзакций и могут быть в состоянии урегулировать подобную ситуацию. WebSphere MQ можно настроить как менеджер ресурсов для единиц работы отдельных серверов приложений J2EE, включая WebSphere Application Server, как было сказано в разделе 4.5.5 "Глобальные единицы работы".

4.6. Межточечный обмен сообщениями

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

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

4.6.1. Извлечение сообщений из очереди

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

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

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

Также приложения могут извлекать ( get ) сообщения из очереди, стирая их из нее и делая их недоступными для других приложений. WebSphere MQ гарантирует, что никакие два приложения не могут успешно изъять из очереди одно конкретное сообщение.

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

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

4.6.2. Размещение служб на основе очередей сообщений

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

Запросы к службе, размещенной на основе очереди, может посылать произвольное количество приложений, которые подключены к инфраструктуре очередей и не владеют данными о доступности службы при отправлении сообщений. Очередь буферизирует сообщения в порядке их постановки, в котором затем эти сообщения могут быть обработаны. Такой порядок работы именуют FIFO (first-in first-out – "первый вошел, первый вышел").

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

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

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

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

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

4.6.3. Счетчики и очереди возврата

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

WebSphere MQ позволяет очередям, откуда извлекаются сообщения, задавать очереди возврата ( backout queue ). Приложение может проверить правильность названия такой очереди и пользоваться ею как местом назначения сообщений, обработка которых вызвала сбой.

Ряд сбоев может не возникать повторно, и дополнительной попытки произвести обработку может оказаться достаточно. Если приложение получает сообщение в ходе единицы работы, которую в дальнейшем откатывает, или выдает ошибку при обработке, WebSphere MQ увеличивает счетчик возвратов ( backout count ) в дескрипторе данного сообщения.

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

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

Примечание WebSphere MQ не переносит сообщения в очереди возврата автоматически.

4.6.4. Службы с управлением по событиям

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

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

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

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

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

4.6.5. Обмен по принципу "отправил – забыл"

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

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

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

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

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

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

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

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

4.6.6. Списки распространения

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

Примечание Эта возможность недоступна в WebSphere MQ для z/OS. Подробности см. в руководстве WebSphere MQ Application Programming Guide, SC34-6595.

4.6.7. Сегментация сообщений

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

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

4.6.8. Логическая группировка сообщений

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

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

4.6.9. Отчеты

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

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

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

4.6.10. Отчеты "подтверждение доставки" и "подтверждение прибытия"

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

Подтверждение прибытия (COA – confirm on arrival). Сообщение прибывает в очередь назначения, которой управляет менеджер целевой очереди.

Подтверждение доставки (COD – confirm on delivery).

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

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

4.6.11. Синхронный обмен по принципу "запрос – ответ"

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

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

Приложение указывает ту очередь ответов (reply-to queue), в которой ждет появления реакции на запрос. Эта очередь может принадлежать одному, а может – совместно использующим ее нескольким приложениям. К обсуждению этого мы вернемся в разделе 4.6.14 "Реализация очереди ответов". Название очереди ответов размещается в дескрипторе сообщения-запроса.

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

Сообщение с запросом действия службы и требованием вернуть ответ по адресу приложения-отправителя в WebSphere MQ помечается как запрос ( request ).

Сообщение с ответом службы на сообщение-запрос приложения-отправителя в WebSphere MQ помечается как ответ ( reply ).

4.6.12. Частично синхронный обмен по принципу "запрос – ответ"

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

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

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

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

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

4.6.13. Истечение срока существования сообщений

Если приложение работает по тайм-ауту, оно должно указать срок существования ( expiry time ) сообщения в дескрипторе отправляемого запроса. Описанное значение в десятых долях секунды устанавливает приложение-инициатор запроса, WebSphere MQ сокращает его для отражения времени, проведенного сообщением в инфраструктуре. Сюда относится время, проведенное в очереди по адресу назначения до приема сообщения службой на обработку, и время во всех транзитных очередях. Когда же срок существования истекает, сообщение уже не смогут принимать приложения, и оно станет пригодным для удаления инфраструктурой.

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

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

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

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

4.6.14. Реализация очереди ответов

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

Использование единой очереди ответов для всех запросов, адресованных службе.

В дескрипторе каждого сообщения в WebSphere MQ содержится идентификатор ( message identifier ), который генерируется WebSphere MQ и может быть уникальным в пределах инфраструктуры.

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

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

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

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

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

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

Использование временной динамической очереди.

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

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

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

Системные ресурсы для поддержания каждой временной динамически создаваемой и удаляемой очереди довольно невелики.

Использование постоянной динамической очереди.

Постоянная динамическая очередь (permanent dynamic queue) организуется при тех же условиях, что и временная, и может использоваться аналогично. Однако WebSphere MQ не удаляет ее из менеджера автоматически, в том числе при закрытии приложения, отправившего запрос. Вместо этого приложение обязано самостоятельно удалить очередь из менеджера очередей после завершения обработки. Этот подход наделен теми же преимуществами, что и работа с временными динамическими очередями, но годится и для использования тогда, когда в составе сообщения-ответа содержится критичная для бизнеса информация.

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

4.6.15. Обработка сообщений службой

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

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

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

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

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

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

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

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

Получить данные для ответа.

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

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

Установить тип сообщения как ответ или отчет.

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

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

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

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

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

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

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

Фиксировать единицу работы.

4.7. Обмен по принципу публикации-подписки

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

4.7.1. Брокер публикации-подписки WebSphere MQ

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

Примечание Брокер публикации-подписки был встроен в WebSphere MQ в пакете Fix Pack 8 для WebSphere MQ Version 5.3 и входит в состав WebSphere MQ Version 6.0. Ранее он поставлялся в пакете SupportPac MA0C.

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

Примечание Здесь мы даем лишь краткое описание возможностей брокера публикации-подписки WebSphere MQ.

Подробнее о публикации и подписке в WebSphere MQ читайте в следующих руководствах:

WebSphere MQ Publish/Subscribe User’s Guide, SC34-6606

WebSphere Business Integration Pub/Sub Solutions, SG24-6088

MQSeries Publish/Subscribe Applications, SG24-6282

Каждый менеджер очередей может управлять максимум одним брокером, имеющим то же название в инфраструктуре, что и менеджер очередей, на котором он расположен. Брокеры могут объединяться в сеть брокеров (broker network), давая возможность приложениям, связанным с одним менеджером, получать публикации в адрес брокера под управлением другого менеджера.

4.7.2. Взаимодействие с брокером публикации-подписки WebSphere MQ

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

Интерфейс брокера "запрос – ответ" для каждого менеджера очередей использует очередь, именуемую очередью управления брокером (broker control queue).

Такие стандартизованные API, как Java Message Service (JMS), могут упростить интерфейс с брокером, сделав необязательными явное формирование и передачу ему команд.

4.7.3. Потоки

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

4.7.4. Регистрация

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

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

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

4.7.5. Темы

Темы определяются брокером по символьным строкам, называемым строкой темы (topic string). Эти строки есть в каждой из публикаций любого источника публикации.

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

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

4.7.6. Публикации

В WebSphere MQ публикации бывают двух видов.

Несохраняемые публикации (non-retained publications).

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

Сохраняемые публикации (retained publications).

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

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

4.7.7. Развитие функций публикации и подписки в WebSphere MQ

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

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

IBM WebSphere Business Integration Message Broker и WebSphere Business Integration Event Broker – это отдельные брокеры, основанные на базовых функциях работы с сообщениями WebSphere MQ и максимально использующие возможности модели публикации-подписки.

Совет. Использование стандартизованных интерфейсов для обращения к службам публикации- подписки может обеспечить гибкость при переходе с базовых возможностей обмена сообщениями публикации и подписки WebSphere MQ на решение на базе WebSphere Business Integration Message Broker или WebSphere Business Integration Event Broker без дорогостоящей модификации приложений.

Страницы: