Ошибка инициализации консоли управления jms

Версия ПО:  JMS  1.x — 3.x

Токены:  Любые

Проблема: 

При запуске консоли управления JMS, настроенной на подключение с использованием SSL, возникает ошибка, представленная на скриншоте ниже:

Причина:

При добавлении отпечатка сертификата в командной строке с использованием команды netsh http add sslcert…, было неверно указано значение ipport=

Решение:

• Необходимо указать значение ipport=, в соответствии с документацией (ipport=0.0.0.0:9010).

1. Введение

2. Функциональные возможности

3. Архитектура и системные требования JaСаrta Management System

4. Работа с JaСаrta Management System

4.1. Управление пользователями

4.2. Управление профилями JMS, глобальными группами и ролями пользователей

4.3. Управление рабочими станциями

4.4. Операции с ключевыми носителями

4.5. Ведение актов и заявок

4.6. Учет СКЗИ

4.7. Ведение электронных журналов

4.8. Настройка уведомлений

5. Работа с ключевыми носителями в Клиенте JMS

6. Выводы

Введение

JaCarta Management System 3.0 (JMS) — корпоративная система управления жизненным циклом ключевых носителей JaCarta, eToken и Рутокен. Она входит в состав семейства аппаратных и программных продуктов JaCarta компании «Аладдин Р. Д.».

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

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

На программное обеспечение JaCarta Management System выдан сертификат ФСТЭК России № 3355, подтверждающий ее соответствие 4 уровню контроля отсутствия недекларированных возможностей и требованиям Технических условий.

JMS зарегистрирована в Едином реестре российских программ для электронных вычислительных машин и баз данных под номером 311 (Минкомсвязь России).

Функциональные возможности

JaСаrta Management System позволяет:

• автоматизировать учет всех ключевых носителей, в том числе сертифицированных СКЗИ. При этом учитываются владелец, номер, модель и срок службы ключевого носителя, а также объекты на нем и рабочие станции, использующие этот носитель;
• управлять всем жизненным циклом ключевых носителей, включая выдачу, перевыпуск и отзыв ключевых носителей и всех связанных с ними объектов (сертификатов, ключей, меток модулей доверенной загрузки и др.);
• централизованно управлять политиками информационной безопасности (ИБ) в отношении ключевых носителей;
• проводить аудит действий пользователей и администраторов с помощью служебных журналов;
• предоставлять сервис самообслуживания для пользователей, позволяя сотруднику самостоятельно совершать операции с ключевыми носителями, осуществляя их выпуск, отключение, синхронизацию, блокирование, разблокирование и замену без обращения в ИТ- или ИБ-отделы;
• формировать и выводить на печать заявки на выдачу ключевых носителей и сертификатов, что позволяет автоматизировать документооборот, связанный с жизненным циклом ключевых носителей;
• отслеживать изменения во внешних системах и обновлять свою базу данных в соответствии с ними;
• отслеживать перемещение ключевых носителей между филиалами и распределять права по администрированию серверов JMS между штаб-квартирой и филиалами;
• осуществлять резервное копирование, сохранять копии выпущенных объектов, общих настроек системы и профилей выпуска объектов, что позволяет гарантировать их сохранность, а также перевыпускать ключевые носители со старыми сертификатами;
• создавать отчеты по ключевым носителям, пользователям, СКЗИ, рабочим станциям, в том числе и по отдельным филиалам.

Благодаря возможностям JMS значительно сокращается время выполнения операций, таких как:

• поддержка многофункциональных ключевых носителей;
• пакетная регистрация ключевых носителей JaCarta;
• «взятие под управление» имеющихся ключевых носителей и объектов на них;
• сохранение перевыпускаемых сертификатов;
• автоматическая синхронизация ключевых носителей;
• работа нескольких серверов JMS в автономном режиме;
• разделение полномочий администраторов в филиальной сети;
• создание кастомизированных запросов к удостоверяющим центрам (УЦ);
• автоматический учет СКЗИ в соответствии с требованиями ФСБ России;
• плавная миграция с SafeNet Authentication Manager (SAM) / Token Management System (TMS).

Сертифицированная версия JMS обеспечивает выполнение требований российского законодательства в области защиты персональных данных и конфиденциальной информации и может использоваться в автоматизированных системах, обрабатывающих конфиденциальную информацию до класса защищенности 1Г включительно, а также в информационных системах персональных данных (ИСПДн) до 1 класса включительно.

Архитектура и системные требования JaСаrta Management System

Рисунок 1. Архитектура JaСаrta Management System

В состав JaСаrta Management System входят следующие компоненты:

• Сервер JMS — ядро JMS, обеспечивающее централизованное управление учетными записями пользователей, ключевыми носителями, политиками и т. д. Возможен вариант установки нескольких серверов в кластере. Поддерживается виртуализация и резервное копирование закрытых ключей, баз данных и настроек системы.
• Консоль управления JMS — Консоль администратора, позволяющая регистрировать пользователей, выполнять операции с ключевыми носителями пользователей, настраивать профили выпуска, создавать и редактировать глобальные группы JMS, выполнять планы обслуживания. Доступные объекты и операции в Консоли соответствуют роли и полномочиям конкретного администратора.
• Клиент JMS — клиентский агент JMS на стороне пользователя, который выполняет функцию синхронизации содержимого ключевого носителя с данными на сервере, а также позволяет пользователю выполнять ряд операций с носителем в рамках сервиса самообслуживания (выпуск, отзыв, разблокировка, замена).
• База данных JMS — обеспечивает централизованное хранение информации об учетных записях пользователей JMS, ключевых носителях, объектах, выпущенных на носителях, политиках, настройках JMS и т. д. Значимая информация хранится в криптохранилище.
• Криптохранилище — виртуальный объект (область базы данных), где хранятся защищенные данные (закрытые ключи, PIN-коды и т. д.). Криптохранилище создается в процессе первоначальной настройки конфигурации JMS. Доступ к монтированию криптохранилища имеет только авторизованный оператор по предъявлению ключевого носителя с сертификатом.
• JMS Server API — открытый API для разработки коннекторов к УЦ и ресурсным системам, собственного клиентского ПО, а также для интеграции с другими ИТ- и ИБ-системами предприятия.

Таблица 1. Системные требования сервера JMS

Таблица 2. Системные требования Консоли управления JMS и Клиента JMS

Работа с JaСаrta Management System

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

Рисунок 2. Интерфейс Консоли управления JMS

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

Управление пользователями

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

Рисунок 3. Пользователи Консоли управления JMS

Предусмотрены два способа регистрации новых пользователей JMS из каталога Active Directory (AD) — выборочный (кнопка «Зарегистрировать») и общий для всех пользователей каталога (кнопка «Зарегистрировать всех»).

Рисунок 4. Окно регистрации новых пользователей

Также в качестве базы пользователей можно использовать базу данных УЦ КриптоПро 1.5 и 2.0. При том, что JMS поддерживает неограниченное число баз пользователей, учетные записи не дублируются, а «склеиваются», что позволяет одному пользователю JMS иметь комбинированный набор атрибутов — из AD и из УЦ.

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

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

Рисунок 5. Назначение временного пароля пользователя для работы с JMS

Управление профилями JMS, глобальными группами и ролями пользователей

Профили JMS позволяют единожды выполнить необходимую работу по настройке политик выпуска. При выпуске нового ключевого носителя администратору достаточно нажать кнопку «Выпустить», и носитель, согласно выбранному профилю, пройдет процедуру инициализации: зададутся нужные политики PIN-кодов, сгенерируются ключевые пары по заданным алгоритмам, будут запрошены и сгенерированы в УЦ, а затем записаны на ключевой носитель (в том числе и удаленно) нужные сертификаты по нужным шаблонам (причем пользователь это может сделать и сам в Клиенте JMS, без обращения к администратору — если ему выданы соответствующие права). Все действия выполняются средствами JMS автоматически без участия человека, без ошибок и без траты времени на подбор параметров при каждом выпуске или обновлении ключевого носителя.

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

• профили выпуска ключевых носителей;
• профили настроек клиентского агента;
• профили инициализации ключевых носителей;
• профили коннекторов со сторонними центрами сертификации.

Рисунок 6. Настройки профилей в Консоли управления JMS

JMS поддерживает создание профилей и настройку их параметров в зависимости от их типа.

Рисунок 7. Параметры нового профиля «Инициализация JaCarta PKI»

Привязки профилей JMS по умолчанию осуществляются к OU (организационная единица в AD). Фильтр безопасности позволяет отменить действие профиля или наоборот добавить профиль к группе пользователей, независимо от их OU. Данный фильтр применяется как к группам AD, так и к внутренним группам JMS («Глобальные группы»), куда пользователи добавляются вручную.

Рисунок 8. Настройка глобальной группы JMS

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

Рисунок 9. Вкладка «Коннекторы» сервера JMS

JMS позволяет задавать следующие профили коннекторов:

• Настройки выпуска сертификатов через УЦ Microsoft CA — позволяет настроить параметры выпуска сертификатов в центре сертификации Microsoft;
• Настройки выпуска сертификатов через УЦ КриптоПро 1.5 — позволяет настроить параметры выпуска сертификатов в центре сертификации КриптоПроверсии 1.5;
• Настройки выпуска сертификатов через УЦ КриптоПро 2.0 — позволяет настроить параметры выпуска сертификатов в удостоверяющих центрах КриптоПро 2.0 и VipNet;
• Выпуск ключевого носителя для использования в JaCarta SecurLogon —позволяет настроить параметры записи профиля Windows в ключевой носитель во время выпуска.

В поставку коннектора JaCarta SecurLogon входят серверный компонент коннектора для установки на сервер JMS и административный компонент коннектора для инсталляции на компьютер, на котором установлена Консоль управления JMS.

Профиль выпуска ключевых носителей для использования с JaCarta SecurLogon создается в Консоли JMS в разделе «Профили».

Рисунок 10. Настройка профиля JaCarta SecurLogon

В JMS предусмотрены стандартные роли (Пользователь, Оператор, Аудитор, Администратор ИБ, Запуск плана обслуживания), каждая из которых включает определенный набор операций. Список доступных ролей отображается в подразделе «Роли» раздела «Пользователи и роли» Консоли управления JMS. Также есть возможность создавать собственные роли с любым набором полномочий и назначать их пользователям, при этом JMS позволяет делегировать управление контейнером ресурсной системы определенным пользователям. Пользователь, которому делегировано управление, сможет выполнять набор разрешенных операций с этим контейнером.

Рисунок 11. Роли пользователей JMS

Рисунок 12. Выбор операций для делегирования

Рисунок 13. Выбор пользователей для делегирования управления

Управление рабочими станциями

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

Рисунок 14. Список зарегистрированных рабочих станций в разделе «Рабочие станции» Консоли управления JMS

Операции с ключевыми носителями

JMS поддерживает следующие операции с ключевыми носителями:

• регистрация ключевых носителей в JMS;
• экспорт и импорт ключевых носителей;
• назначение ключевого носителя пользователю;
• выпуск ключевого носителя администратором;
• одобрение администратором использования незарегистрированного ключевого носителя, подсоединенного пользователем;
• включение/отключение возможности использования ключевого носителя;
• синхронизация ключевых носителей;
• отзыв ключевого носителя;
• замена ключевого носителя;
• возврат в эксплуатацию ключевого носителя;
• разблокировка подсоединенного ключа в удаленном режиме;
• замена отпечатков пальцев, сохраненных в памяти JaCarta PKI/BIO.

Управление ключевыми носителями осуществляется в разделе «Ключевые носители» Консоли управления JMS.

Рисунок 15. Управление ключевыми носителями в Консоли управления JMS

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

Рисунок 16. Подключенные ключевые носители в Консоли управления JMS

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

Рисунок 17. Регистрация нового ключевого носителя

JMS позволяет экспортировать ключевые носители на другой экземпляр JMS. Существует два варианта экспорта:

• экспорт заранее подготовленного списка ключевых носителей;
• экспорт ключевых носителей, выбранных в интерфейсе Консоли управления JMS.

Рисунок 18. Утилита генерации списка экспортируемых ключевых носителей

JMS позволяет назначить пользователю выбранный ключевой носитель.

Рисунок 19. Назначение ключевого носителя

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

Рисунок 20. Выпуск ключевого носителя

JMS позволяет вывести ключевой носитель из эксплуатации — временно отключить возможность использования ключевого носителя (при этом автоматически приостанавливается действие сертификатов в УЦ), отозвать (при этом сертификаты в УЦ отзовутся автоматически) или заменить ключевой носитель. Возможна замена ключевого носителя без выпуска нового сертификата с восстановлением старого сертификата из резервной копии, если она делалась при первоначальном выпуске.

Рисунок 21. Отключение ключевого носителя

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

При работе с ключевыми носителями JaCarta PKI/BIO администратор может с Консоли управления JMS заменить биометрические данные пользователя (отпечатки пальцев), сохраненные в памяти ключевого носителя.

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

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

Рисунок 23. Выбор контейнера ресурсной системы для привязки

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

Рисунок 24. Ввод административного PIN-кода приложения и его подтверждение

JMS позволяет выполнить экспорт резервных копий закрытых ключей и соответствующих им сертификатов, выпущенных на ключевые носители, в виде контейнера PFX. Экспортировать можно не только действующие закрытые ключи и сертификаты, но и ранее удаленные с ключевых носителей. Такая возможность предусмотрена для закрытых ключей и сертификатов, которые были выпущены с помощью УЦ Microsoft, КриптоПро УЦ 1.5/2.0.

JMS предоставляет возможность взять под управление ключевые носители (и объекты, содержащиеся в их памяти), выпущенные до установки и настройки JMS, в том числе ключевые носители, содержащие объекты, выпущенные сторонними УЦ. Например, в организации до установки JMS имеются ключи, в память которых записаны сертификаты, выпущенные на имя пользователей с помощью УЦ Microsoft. Администратор может настроить параметры выпуска этих ключевых носителей в JMS таким образом, чтобы они были взяты под управление без повторного выпуска сертификатов, уже содержащихся в памяти этих ключевых носителей.

Взятие под управление может относиться к следующим типам объектов, содержащимся в памяти ключевого носителя:

• сертификаты УЦ Microsoft;
• сертификаты КриптоПро УЦ 1.5;
• сертификаты КриптоПро УЦ 2.0;
• сертификаты ViPNet УЦ 4.6;
• профили JaCarta SecurLogon.

Рисунок 25. Выбор криптопровайдера, с помощью которого выпускался внешний объект (сертификат на ключевом носителе), при настройке профиля «Внешние объекты»

Ведение актов и заявок

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

Рисунок 26. Работа с актами и заявками в Консоли управления JMS

Учет СКЗИ

JMS позволяет вести учет СКЗИ (включая ключевые документы и нормативные документы). Учет ведется при выпуске сертификатов с помощью коннекторов к УЦ КриптоПро 1.5/2.0 и ViPNet УЦ 4.6.

Функция учета СКЗИ является лицензируемой. Если лицензия на функцию учета СКЗИ отсутствует или истекла, то пользовательский интерфейс Консоли управления JMS скрывает вкладку учета СКЗИ.

Рисунок 27. Учет СКЗИ в Консоли управления JMS

Функции учета СКЗИ приведены в таблице 3.

Таблица 3. Функции учета СКЗИ средствами JMS

Ведение электронных журналов

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

Рисунок 28. Электронный журнал JMS

Настройка уведомлений

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

Таблица 4. Настройка параметров уведомлений

Рисунок 29. Окно настройки SMTP

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

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

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

Рисунок 31. Параметры выпуска ключевого носителя

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

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

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

Выводы

Основное преимущество внедрения и использования JMS — это сокращение финансовых и временных затрат на поддержание инфраструктуры открытых ключей при повышении уровня ИБ. Удобство пользователей повышается за счет автоматизации работы с ключевыми носителями. JMS позволяет централизованно управлять доступом к корпоративным системам и получать информацию обо всех действиях в отношении ключевых носителей.

Основная идея создания JMS — полноценная поддержка ключевых носителей и смарт-карт нового поколения JaCarta. Также система поддерживает Рутокен и eToken, в том числе модели eToken ГОСТ и eToken PRO (Java).

JMS интегрируется с другими продуктами российских вендоров (УЦ, СКУД и др.) путем разработки дополнительных коннекторов.

Сертифицированная версия JMS обеспечивает выполнение требований российского законодательства в области защиты персональных данных и конфиденциальной информации и может использоваться для защиты информации в ИСПДн до 1 уровня включительно и при создании автоматизированных информационных систем до класса защищенности 1Г включительно. Также JMS дополнительно обеспечивает соблюдение требований регуляторов в части учета СКЗИ.

Из явных недостатков JMS можно выделить работу только с компьютерами под операционной системой Microsoft Windows (не поддерживаются Linux и macOS). В ближайшем будущем разработчик планирует выпустить версию Клиента JMS для Linux.

В этой и следующей статье пойдет речь о технологии Java Message Service (JMS). JMS — это система передачи сообщений, изначально разработанная компанией Sun, чтобы предоставить разработчикам создавать гибкие и слабосвязанные приложения с использованием асинхронного обмена данными между приложениями (клиентами/серверами) через посредника. Асинхронность — это главная причина создания и использования JMS.

Принцип работы

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

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

При жестком связывании имеются две главные проблемы, которые и решает JMS:

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

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

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

Модели передачи сообщений

В JMS имеется две модели (домена) передачи сообщений и соответственно для этого используются два вида объекта:

• Модель Точка-Точка (Point-to-Point). Объект Queue.
• Модель Подписчик-Издатель (Publisher-Subscriber). Объект Topic.

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

В модели Pub/Sub сообщение получает каждый подписчик.

1Итак, если Вас кто-то спросит, чем отличается домен Queue от Topic, Вы смело, глядя собеседнику в глаза, ответите: Queue реализует модель PtP и одно сообщение может получить только один получатель, а Topic реализует модель Pub-Sub, что позволяет отсылать одно сообщение множеству клиентов.

Интерфейсы JMS

В версии JMS 1.0 были различные интерфейсы для каждого из домена. С выходом JMS 1.1 появился общий, унифицированный интерфейс для работы с одновременно двумя доменами. Рассмотрим главные интерфейсы:

Интерфейсы JMS

ConnectionFactory	Объект, создающий Connection. В параметре инициализации нужно передавать данные вашего JMS сервера.
Connection	Соединение с сервером JMS. Создает объект Session.
Session	Контекст реализующий передачу и получение сообщений. Управляет транзакцией в JMS и его использование разными потоками невозможно или ограничено. Рекомендуется создавать разные Session для каждого потока. Создает объект Destination.
Destination	Объект, хранящий адреса сообщений (имя топика или очереди). С его помощью создаются объекты, отвечающие за отсылку сообщений на конкретно указанный адресат и их получения оттуда.
MessageProducer	Объект для отправки сообщений.
MessageConsumer	Объект для получения сообщений.

Алгоритм создания программ, работающих с JMS

Весь алгоритм, при желании, можно просчитать по таблице интерфейсов:

1. Подключаемся к серверу, используя ConnectionFactory.
2. Получаем соединение Connection из ConnectionFactory.
3. Создаем однопоточный контекст Session из соединения.
4. Получаем буфер Destination привязанный к определенному адресу для создания интерфейсов отправки и получения сообщений.
5. Создание объектов MessageProducer для отправки или MessageConsumer для получения сообщений.
6. Отдельно идет этап создания сообщения для отправки.

Сообщения в JMS

Сообщения в JMS бывают следующего типа:

Типы JMS сообщений

StreamMessage	Как видно из названия, это поток примитивных типов Java. Считывать можно со стандартных интерфейсов ввода/вывода.
MapMessage	Содержит информацию на подобии коллекций в виде ключ-значение (String, Object).
TextMessage	Обычное, текстовое сообщение.
ObjectMessage	Для передачи Serializable-объектов. Можете передавать сразу классы.
BytesMessage	Список не интерпретированных байт. С его помощью можно передавать файлы.

Любое JMS сообщение имеет в себе 3 составные части:

1. Заголовок (header). Набор свойств, поставляемый по умолчанию для любого сообщения, в их числе информация об отправителе, получателе, о самом сообщение и др. Подробнее о свойствах заголовков ниже.
2. Свойства (properties). Дополнительный набор свойств, составляемый разработчик.
3. Тело (body). Само содержимое сообщения.

Заголовок JMS сообщения

Все параметры заголовка сообщения имеют префикс JMS
Методы установки и считывания их свойств будут выглядеть соответственно setJMS и getJMS.

Параметры заголовка сообщения

Наименование	Тип	Описание
JMSMessageID	String	Параметр идентификации сообщения.
JMSDestination	String	Адрес передачи сообщения.
JMSDeliveryMode	int	Может иметь только два значения: DeliveryMode.PERSISTENT и DeliveryMode.NON_PERSISTENT. Персистентное сообщение доставляется «один раз и только один раз»; не персистентное сообщение доставляется «не более одного раза». «Не более одного раза» подразумевает возможность отсутствия доставки. Для гарантирования отсутствия влияния системных сбоев на доставку персистентных сообщений должны выполняться дополнительные действия. Для передачи персистентных сообщений часто необходимы значительные дополнительные накладные расходы, и нужно тщательно рассматривать баланс между надежностью и производительностью при выборе режима доставки сообщения.
JMSTimestamp	long	Время доставки сообщения JMS серверу для последующей передачи.
JMSExpiration	long	Время жизни сообщения. 0 — означает что сообщение будет жить пока оно не будет доставлено.
JMSPriority	int	Приоритет сообщения от 0 (самый ничтожный) до 9 (наивысший приоритет).
JMSCorrelationID	String	Необходимо для связи ответного сообщения с определенным сообщением-запросом. В это поле помещается JMSMessageID сообщения, на которое необходим ответ.
JMSReplyTo	Destination	Указание места, куда должно быть передано ответное сообщение. Например, все вопросы вы помещаете в топик question, а ответы на них хотите видеть в топике response.
JMSType	String	Тип сообщения.
JMSRedelivered	Boolean	Означает, что сообщение было доставлено получателю, но он не подтвердил прием сообщения.

Транзакции в JMS

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

Возможна кроссдоменная транзакция с использованием JTA.

Пока с теорией закончим. Мы поняли, что это за зверь — JMS, его отличительные особенности и внутреннюю архитектуру.

JAAS

Для аутентификации и авторизации клиентов, во всех MQ серверах возможно использование технологии JAAS. С ней можно познакомиться в одной из статей из серии JavaEE.

Выбор MQ сервера

Используемый нами ранее в JavaEE проектах Glassfish-сервер поддерживает возможность реализации JMS. Однако в реальных «боевых» условиях, поставляемый стандартный функционал JMS от GlassFish практически не используется. Как правило, сервер приложений и сервер сообщений — это абсолютно два разных процесса и расположены на разных машинах. Чаще всего вам придется сталкиваться с другими популярными MQ серверами, такими как:

• Apache ActiveMQ Server
• WebShpere MQ Server

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

В нашем случае мы будем использовать ActiveMQ сервер от Apache.

Установка ActiveMQ сервера

 Для пользователей Windows все будет очень просто:

1. Скачиваем архив сервера с сайта.
2. Разархивируем архив и в папке bin запустим bat файл activemq.bat.

Для пользователей Linux задача чуть усложнится. Приведу пример установки на ОС Ubuntu:

1. Также скачиваем архив с сайта.

   wget http://www.apache.org/dyn/closer.cgi?path=%2Factivemq%2Fapache-activemq%2F5.7.0%2Fapache-activemq-5.7.0-bin.tar.gz

   

2. Разархивируем его

   sudo tar xvfz apache*.tar.gz

3. Перейдем в созданный каталог, там найдем папку bin и в ней выполним команду для создания файла настроек сервера:

   sudo ./activemq setup /etc/default/activemq

4. Если Вы последнее время сильно не грешили, то ActiveMQ должен запуститься командой:

   sudo ./activemq start

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

Сейчас сервер ActiveMQ запущен и готов принимать сообщения на порту 61616.

 Знакомство с сервером ActiveMQ

Уже сейчас, Вы можете протестировать сервер, отправляя и получая сообщения, используя веб-консоль, которая находится на порту 8161 (http://localhost:8161).

Поисследуйте возможности этой веб-консоли. Посмотрите примеры реализации некоторых способов связи с сервером.

В следующей статье мы научимся посылать и принимать различные сообщения из нашего веб-приложения, используя стандартные интерфейсы javax.jms.*, поставляемые с JavaEE 6.

Я работаю над MDB в wildfly 8.2.0. Используемая конфигурация сервера является standalone-full-ha.xml. Я получаю ниже трассировку ошибки, когда выполняется Connection connection = connectionFactory.createConnection().

TRACE [org.hornetq.core.client] (pool-14-thread-1) getConnectionWithRetry::1 with retryInterval = 2000 multiplier = 1.0: java.lang.Exception: trace
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:1103)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:266)
at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:881)
at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)

фрагмент кода

       try {
                InitialContext initialContext = new InitialContext();
                Object objRef = initialContext.lookup("java:/ConnectionFactory");
                ConnectionFactory connectionFactory = (QueueConnectionFactory) objRef;
                Connection connection = connectionFactory.createConnection();
            } finally {
                initialContext.close();
            }

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

Это проблема с именем JNDI java: /ConnectionFactory?

Фрагмент кода

ObjectMessage objMsg = (ObjectMessage) msg;     
Context c = (Context) objMsg.getObject();

ошибка

ERROR [org.hornetq.ra] (Thread-2 (HornetQ-client-global-threads-23377593)) HQ154004: Failed to deliver message: javax.jms.JMSException: com.test.Context from [Module "org.hornetq:main" from local module loader @13205e1 (finder: local module finder @1201837 (roots: D:wildfly-8.2.0.Finalmodules,D:wildfly-8.2.0.Finalmodulessystemlayersbase))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_67]
at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_67]
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:625) [rt.jar:1.7.0_67]
at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass0(ObjectInputStreamWithClassLoader.java:127) [hornetq-core-client-2.4.5.Final.jar:]
at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:55) [hornetq-core-client-2.4.5.Final.jar:]
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612) [rt.jar:1.7.0_67]
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517) [rt.jar:1.7.0_67]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) [rt.jar:1.7.0_67]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) [rt.jar:1.7.0_67]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_67]
at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:155) [hornetq-jms-client-2.4.5.Final.jar:]

Нужно ли изменять значение атрибута jms-connection-factory ниже из java:jboss/DefaultJMSConnectionFactory для java: /ConnectionFactory или любой другой проблемы с конфигурацией?

<subsystem xmlns="urn:jboss:domain:ee:2.0">
...
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:/TestDB" jms-connection-factory="java:jboss/DefaultJMSConnectionFactory" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
</subsystem>

Пожалуйста, помогите мне, почему возникает ошибка и как ее решить. Большое спасибо.