Рекомендуемый ответ с точки зрения безопасности состоит в том, что другая организация должна требовать, чтобы вы использовали полный QMgr, а не клиент. Канальное соединение от внешнего QMgr всегда будет выдавать только команды CONNECT, INQUIRE и PUT. Клиентское соединение имеет доступ ко всему API WMQ и может выполнить любой вызов API для любого объекта. Например, если другая сторона использует структурированные данные в своих именах очереди (например, номер счета), клиентское приложение может циклически перебирать все возможные имена, чтобы перечислить все номера счетов. Если вызов возвращает 2035, объект существует, но авторизация не удалась. Если вызов возвращает 2085, объект не существует. В дополнение к разрешению различных типов перечисления клиент, который застревает в цикле соединения, может бросать сотни попыток повторного соединения в секунду в QMgr, который полностью связывает слушателя. Таким образом, клиенты по своей природе более опасны для приема соединений от QMgr, а клиенты от третьих лиц - тем более. Однако клиенты бесплатны, а стоимость часто перевешивает риск, особенно если приложение не перемещает транзакции с высокой стоимостью или конфиденциальные данные. Если бы мне было предъявлено обвинение в подключении к QMgr поставщика, и они разрешили выбор клиентских подключений или подключений QMgr, а приложение было высоконадежным или критичным, я бы выбрал полный QMgr.
Другим аспектом, который следует учитывать, является то, что каналы QMgr-QMgr более устойчивы к проблемам сетевого подключения. Это связано с тем, что два QMgrs отслеживают порядковые номера сообщений, удерживают пакеты в точке синхронизации до тех пор, пока не будут подтверждены, и способны автоматически согласовывать восстановление канала без потери или дублирования каких-либо постоянных сообщений. Поскольку клиентский канал предоставляет вам, как разработчику, полный доступ к API, включая свободу писать программы, которые жертвуют надежностью ради производительности, можно написать клиентское приложение, которое теряет или дублирует сообщения. Фактически, проблема, связанная с асинхронным сообщением по сети, заключается в том, что проблемы восстановления сеанса могут привести к неоднозначным результатам, которые приводят к дублированию сообщений. Это не относится к WebSphere MQ, и фактически в спецификации JMS говорится об этой проблеме и отмечается, что приложение несет ответственность за должный учет «функционально дублированных» сообщений, созданных в результате восстановления сеанса. Вы можете исключить возможность потери сообщения, всегда используя транзакционные сеансы, но устранение возможности отправки двойного сообщения занимает немного работы. Два говорящих QMgrs используют протокол, который устраняет любую такую двусмысленность.
Что касается показателей производительности, взгляните на отчеты о производительности для вашей платформы. Все они доступны на целевой странице SupportPacs . Найдите SupportPac с именами, такими как MP**, например SupportPac MP71 для Windows или SupportPac MPL5 для Linux.