IBM MQ

IBM MQ — это семейство ориентированных на сообщения промежуточных программных продуктов, которое IBM запустила в декабре 1993 года. Первоначально оно называлось MQSeries и было переименовано в WebSphere MQ в 2002 году для присоединения к набору продуктов WebSphere . В апреле 2014 года оно было переименовано в IBM MQ . Продукты, входящие в семейство MQ: IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ for z/OS и IBM MQ on IBM Cloud. IBM MQ также имеет варианты контейнерного развертывания.

MQ позволяет независимым и потенциально непараллельным приложениям в распределенной системе безопасно взаимодействовать друг с другом, используя сообщения. MQ доступен на большом количестве платформ (как IBM, так и не-IBM), включая z/OS ( мэйнфрейм ), IBM i , Transaction Processing Facility , UNIX ( AIX , HP-UX , Solaris ), HP NonStop , OpenVMS , Linux и Microsoft Windows .

Основными компонентами MQ являются:

• Сообщение : Сообщения представляют собой наборы двоичных или символьных (например, ASCII или EBCDIC ) данных, которые имеют некоторое значение для участвующей программы. Как и в других протоколах связи , информация о хранении, маршрутизации и доставке добавляется к сообщению перед передачей и удаляется из сообщения перед доставкой принимающему приложению.
• Очередь : Очереди сообщений — это объекты, хранящие сообщения в приложении.
• Queue Manager : системная служба, которая предоставляет логический контейнер для очереди сообщений. Она отвечает за передачу данных другим менеджерам очередей через каналы сообщений. Хотя это не является строго обязательным для промежуточного программного обеспечения, ориентированного на сообщения, это предварительное условие IBM MQ. Менеджеры очередей обрабатывают вопросы хранения, синхронизации, запуска и все другие функции, не связанные напрямую с фактическим перемещением данных.

Программы, интегрированные с IBM MQ, используют единый интерфейс прикладных программ (API) на всех платформах.

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

API, напрямую поддерживаемые IBM, включают:

• Интерфейс очереди сообщений IBM (MQI) для C , COBOL , PL/I , Java , Rexx , ^[1] RPG и C++
• Служба сообщений Java (JMS)
• XMS для C/C++ и .NET ^[2]
• .СЕТЬ
• ОТДЫХ
• МЫЛО

Дополнительные API (официально не поддерживаемые) также доступны через третьих лиц, в том числе:

• Интерфейс Perl (разработанный и предоставленный Хильдо Бирсма), доступен на CPAN . ^[3]
• Интерфейс Python PyMQI (первоначально разработанный Лесом Смитсоном), доступен на PyPI ^[4]
• PowerShell ^[5]

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

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

Преобразование данных : например, Big Endian в Little Endian или EBCDIC в ASCII . Это достигается с помощью использования выходов данных сообщений. Выходы — это скомпилированные приложения, которые работают на хосте менеджера очередей и выполняются программным обеспечением IBM MQ в момент, когда требуется преобразование данных.

Архитектура, управляемая сообщениями : IBM MQ позволяет получать сообщения для «запуска» других приложений.

Диапазон API : Он реализует стандартный API Java Message Service (JMS), а также имеет свой собственный API, известный как Message Queuing Interface (MQI), который существовал несколько лет до JMS. Начиная с версии 8.0.0.4, MQ также поддерживает MQ Light API.

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

Менеджеры очередей общаются с внешним миром посредством:

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

Это зависит от канала . Каждый менеджер очередей использует один или несколько каналов для отправки и получения данных другим менеджерам очередей. Канал является однонаправленным; для возврата данных требуется второй канал. В сети на основе TCP/IP канал отправляет или получает данные на определенном порту.

Типы каналов:

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

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

Прослушиватель — это сетевой интерфейс приложения к менеджеру очередей. Прослушиватель обнаруживает соединения с входящих каналов и управляет соединением отправляющих каналов с принимающими каналами. В сети TCP/IP прослушиватель будет «прослушивать» соединения на определенном порту.

Типы очередей:

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

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

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

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

MQ поддерживает как циклическое, так и линейное ведение журнала.

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

IBM MQ предлагает ряд решений для обеспечения доступности:

Диспетчер очередей реплицированных данных (RDQM / «Easy HA» — MQ Advanced только для распределенных систем): синхронная репликация между тремя серверами, которые имеют общий плавающий IP-адрес.

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

Группы общего доступа к очередям (только z/OS): В среде общей очереди приложение может подключаться к любому из менеджеров очередей в группе общего доступа к очередям. Поскольку все менеджеры очередей в группе общего доступа к очередям могут получать доступ к одному и тому же набору общих очередей, приложение не зависит от доступности конкретного менеджера очередей. Это обеспечивает большую доступность, если менеджер очередей останавливается, поскольку все остальные менеджеры очередей в группе общего доступа к очередям могут продолжать обработку очереди.

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

Следующая таблица относится к программному обеспечению MQ. MQ Appliance имеет другие даты жизненного цикла как для прошивки, так и для оборудования, чем те, что указаны в таблице. ^[11]

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

В начале 1960-х годов IBM выпустила на рынок систему управления связью IBM 7740 и систему управления программируемой передачей IBM 7750, которые представляли собой программируемые системы коммутации сообщений.

IBM System/360 была анонсирована в апреле 1964 года, и вместе с ней появились методы доступа к коммуникациям, такие как BTAM и QTAM (Basic and Queued Telecommunications Access Methods). В 1971 году TCAM, Telecommunications Access Method , предложил своим пользователям более продвинутую форму коммутации сообщений или маршрутизации сообщений. TCAM получил широкое распространение, особенно в финансовой и брокерской отраслях. Он поддерживал асинхронный обмен сообщениями, как и более поздний MQ. TCAM 3.0 добавил повторно используемые дисковые очереди сообщений для восстановления вскоре после этого, как и в MQ. Высокоуровневая программа PL/I могла использоваться для доступа к наборам данных TRANSIENT (динамическим очередям сообщений). Чтение сообщения из набора данных transient приводило к удалению этого сообщения из очереди, как и в случае с непросмотровым READ с MQ.

В конце 1970-х годов появились системы управления транзакциями, каждая из которых пыталась занять лидирующие позиции в отрасли. В IBM CICS и IMS были выбраны в качестве стратегических продуктов для решения проблемы управления транзакциями. В CICS и IMS у каждой была своя версия коммутации сообщений, IMS была системой с очередями на внешнем интерфейсе, а CICS имела свой механизм Transient Data в качестве возможной основы для коммутации сообщений. ^{[ необходима цитата ]}

CICS зарекомендовала себя как популярная система управления транзакциями в период с 1968 по 1971 год. Те пользователи, которые приняли TCAM из-за его возможностей обработки сообщений, теперь хотели комбинированного использования TCAM с CICS. В декабре 1971 года IBM объявила о поддержке CICS TCAM как части продукта CICS/OS-Standard, который должен был быть поставлен в декабре 1972 года. Для заинтересованных клиентов это позволило использовать TCAM из-за его сильных сторон обработки сообщений, а также иметь подключенные к TCAM терминалы или компьютеры, взаимодействующие с онлайн-приложениями CICS. ^{[ необходима цитата ]}

В январе 1973 года TCAM продолжал поддерживаться CICS/OS-Standard Version 2.3. Однако поддержка TCAM была исключена из первоначального выпуска CICS/VS, анонсированного в феврале 1973 года и выпущенного в июне 1974 года. Излишне говорить, что многие клиенты CICS-TCAM были недовольны таким направлением продукта.

Под значительным давлением со стороны клиентов CICS-TCAM поддержка TCAM со стороны CICS была восстановлена ​​в продукте CICS/VS 1.1 в сентябре 1974 года. В дополнение к предыдущей поддержке DCB, с этим восстановлением поддержки TCAM, CICS начал поддерживать доступ к TCAM через VTAM, также известный как поддержка ACB. Поддержка CICS TCAM ACB была прекращена с продукта CICS/ESA Version 3 в 1990 году.

В 1992 году IBM анонсировала новый продукт под названием MQSeries. Этот бренд был позже переименован в WebSphere MQ (однако его официальное сокращенное название оставалось MQ) в 2002 году для поддержки имени семейства WebSphere и продукта. В 2014 году он был переименован в IBM MQ. MQ должен был стать расширением функциональности TCAM из систем только IBM на все другие платформы. MQ имеет архитектуру, которая позволяет гетерогенным системам взаимодействовать друг с другом (например, IBM, HP, Sun, Tandem и т. д.). MQ можно использовать с системами CICS для отправки и получения данных в/из любой другой системы, соответствующей требованиям MQ. MQ можно использовать для инициирования работы в системе CICS, или транзакция CICS может инициировать работу в другой системе CICS или не-CICS.

IBM MQ теперь поддерживает 80 различных сред и стал ведущим в отрасли продуктом коммутации/маршрутизации с гарантированной доставкой сообщений. ^[12]

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

Связанный продукт в семействе продуктов IBM MQ, называемый IBM App Connect Enterprise (ранее IBM Integration Bus / WebSphere Message Broker), обеспечивает разнообразный и надежный набор расширений для архитектур на основе очередей. Используя IBM Integration Bus, пользователи могут реализовать интерфейс WebServices, дополненный поддержкой файлов WSDL , который может взаимодействовать с любым приложением на основе очередей.

• Расширенный протокол очереди сообщений
• IBM WebSphere Message Broker
• Служба сообщений Java
• Очередь сообщений
• Очередь сообщений как услуга
• MQTT

Послушайте эту статью ( 22 минуты )

Этот аудиофайл был создан на основе редакции этой статьи от 29 октября 2011 года и не отражает последующие правки. ( 2011-10-29 )

( Аудиопомощь  · Больше устных статей )

• Страница продукта IBM MQ